Developing with Roost
- Harish Agrawal
Here is a typical scenario that we want the developer team(s) to follow and how Roost solves their need.
About the Application:
The application captures votes from the end-user and provides a distribution of the total as a final result. There are a minimum of 2 micro-services built by different teams that come together to complete the functionality.
Microservice & Team:
Microservice | Team/Langugage | Git Repo |
|---|---|---|
Ballot API | API (Golang) | github.com/acme/ballot.git |
Voter UI | UI (NodeJS, React JS) | github.com/acme/voter.git |
Application Dependency:
Voter UI calls Ballot API to complete the voting transaction
Environments and Roost:
There can be 3 or more environments with the team.
Environment | Access Scope | Roost Perspective | Usage |
|---|---|---|---|
DEV | Individual | Local Cluster and dedicated | For build, unit test and peer collaboration |
SIT | Whole Team | Remote Roost Cluster configured as team cluster | Individuals stage their deployments on this team cluster. |
UAT & PROD | Restricted | Can be any cluster (beyond Roost) | Typically integrated with JX pipeline for automation |
Development Flow
Developer spins up Local Roost cluster and writes the code
Generates DockerFile and k8s yaml
Builds and deploys the code in the Local Roost cluster
Iterates the above step, till the unit-tests are all good
Collaborates the yaml along with docker images amongst peer for further validation.
Switches to the team & team cluster
Deploys the yaml (& image) to team cluster
This triggers “Roost Service Fitness”
Roost Service Fitness Framework
The fitness framework is driven by the Application Manifest. This is to be defined once for the application by the team architect or team lead. Service Fitness Framework