We form the dev teams by business domains, for example, Order, Article, or Inventory team.
Each team consists of 1 Product Owner and 4 to 5 devs.
The cross-functional teams can do all Frontend, Backend, DevOps, and QA tasks.
We develop new features within every 2-weeks, called "Sprint."
All teams hold a daily standup in the morning to quickly talk about what we did yesterday, what we're going to do today, and what is blocking us at the moment.
At the beginning of each Sprint, we have a "Sprint-planning" meeting where we plan and estimate new features that we will develop in the next two weeks.
Our Product Owner writes each new feature in one Story ticket on the Kanban board. After that, the devs will split the ticket into smaller sub-tasks. Each sub-task should be small enough to build, test and deploy within one day.
The tickets will move through 5 main columns on Kanban board: Backlog -> In Progress -> In Code Review -> In QA -> Done
We only have one main git branch (also called
main). Everyone uses this branch to deploy the code to the development environment for testing. We will deploy the code from this main branch to production at the end.
(Note) We containerize all the services and use Terraform or CloudFormation to define the infrastructure.
When devs start with a new feature, a new feature branch will be branched off from
mainwith the ticket name at the beginning of the branch name, for example,
FEAT-2192-build-create-order-endpoint. All code commits must have the ticket name too.
After implementing the new feature, the devs will make a Pull Request for others to review. At this point, the CI/CD pipeline will run the tests and linting. Only when all pass, then the Pull Request is ready.
Code reviewers will check for coding style, tests, potential bugs, etc. And approve it if everything is ok.
The devs merge new code to the main branch. After that, CI/CD pipeline will deploy the code to the development environment.
Other devs or QA engineers in the same team will test the new feature on development environment.
Finally, when QA engineers approve, someone can click the deploy button and trigger CI/CD pipeline to deploy the code to production.
At the end of the Sprint, we have a Retrospective meeting where the team discusses what went well and what not to improve the process next Sprint.
Continue to Step 1. and start a new Sprint.
- Git, Github for version control.
- Github Action to build CI/CD pipelines.
- Kubernetes and Docker.
- Terraform to define infrastructure.
- AWS services.
- Jira for Kanban board, Confluence for writing documents and Wiki pages.
- Slack for communication.
- Bitwarden for storing password.