Summary
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.
The tech stack that we use
- 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.
Top comments (11)
Great insight thanks for sharing.
When you pushing a deadline..throw this stuff out da window
Pure gold... Thank you for sharing ❤️
Thanks ❤️
Are you using any branch for the productive code? It looks like this is not the case, so is it correct, that a certain commit of your main branch, which is for development, contains the productive code?
Hi there!
We use the main branch for both the development and production environment. So new commits to this branch are always automatically deployed to the development env. But we only deploy specific commits to production manually.
So yea, the feature branches (branched off from the main branch) always include the latest productive code.
Amazing post, but just wondering why do you need ticket name for each feature?
Hi Munezero,
Thank you for being interested in my post!
We add the ticket name for the following reasons:
Have a nice day! :)
This is how we do it as well. Main branch and feature branches. Rather easy to maintain and do deployments. Has its pros and cons though.
how is the process to make new releases? does you make tag branches in the github?
Hi Walace,
We only use the main branch to deploy new code to Production. The team will manually choose a specific commit on this branch for deployment.