Get Started with Git — DevOps Roadmap
It is necessary to seek answers to specific questions from the Git process. How many people are in your team? How many features are in development at the same time? What is your release frequency? Contains variables such as The more complex the scenario, the better the strategy should be.
Developer expectations:
See the history of changes made to the code.
To compare these changes with the previous version and to undo them if necessary.
If there is an error that needs to be resolved and deployed, ensure that the developments that are being worked on are continued without being affected by this error.
Team expectations:
Developing and submitting improvements without affecting teammates.
Merging the developments without affecting the team and solving the conflicts that will arise in the meantime in the easiest way.
Ensuring code quality and basic standards independent of the number of people working on the project.
Default Flow
In this model, we have two branches, master and develop. Each tagged version is exited through the master branch. This structure can generally be called a branch model of a project started from scratch. It continues like this until the first version is released or the first feature is completed. In this model, when working on a new feature, there is no transaction in the master branch. The advantage here is that if there are bugs to be resolved, they can be fixed instantly without the need to stash the developments we are working on or try to finish them quickly. After creating and resolving a separate branch for the bug, it merges with the master and a new tag release is created.
This pattern might work well in a developer project. However, it is possible to resolve the process, which will start to cause problems in the future, with CI, albeit a little.
Git Flow
The master branch should be the master branch for us. Codes in the master branch can be thought of as the product published or ready for publication. Development, on the other hand, should be the branch with the final version of the project to be released in the development phase and the next release. After all the tests in the development branch are completed, they should be merged into the master branch. The last step should be tagging the final version after each merge and update.
Apart from the master and development branches, there should be feature branches to support these branches. The point here is to ensure that the different developments that are carried out by different team members at the same time continue without causing confusion, to facilitate the follow-up of the development process as different branches are fragmented, to be ready for the next release and to quickly solve the problems of the application in production.
Several branches can be created to support this situation. These can be called feature, release and hotfix. These branches, named based on the work done, have goals and clear rules.
feature branch
It is the branch model with improvements in the next version.
It should be created from the development branch and merged into the development branch again.
It should be in the development repo.
release branch
Its purpose should be to support the new update process.
Minor bug fixes can also be made in this branch.
The preparation of meta-data such as version number, build date is done here.
It is created from the development branch and again merged into the development or master branch.
hotfix branch
It is derived from the master branch and merged into the development or master branch.
It has a very similar structure to the release branch.
It is created to solve a critical bug in production. It is removed from the production tag number and merged again.
The biggest advantage is that while the other developers in the team continue their work, the other person can solve this bug in a separate environment.
features/feature-name,
features/feature-area/feature-name
users/username/description
feature/issue-tracker-number/short-description
GitHub Flow
GitHub Flow was created by GitHub in 2011. To work on a new feature, a branch is created from the master. These branch enhancements are pushed regularly. If it is ready for feedback or merging, a pull request is opened. The feature is reviewed and merged into the master.
Once merged and pushed to the master, it can be deployed immediately.
Suitable for CI and CD.
It is a simpler alternative to Git Flow.
Ideal when a single version needs to be maintained in production.
Production can most easily become unstable.
It’s not enough when it needs release plans.
It doesn’t fix anything about distribution, environments, versions and issues.
Not recommended when multiple versions are required in production.
Trunk-Based Development
Teams should adopt trunk-based development techniques to make CI/CD fast. Since it is a completely CI-focused model, long-living development branches that can cause merge hell are avoided. Trunk-Based Development enables developers to continuously integrate the features they have developed separately, by making improvements through a single branch (trunk or master or main). One of the points to be considered while doing Trunk-based Development is to prevent end-users from seeing this unfinished development in the prod environment by using the feature toggle technique, in case the code is likely to go live when trunk commits.
Trunk-Based Development is an important building block of CI/CD culture. It encourages developers to commit frequently, these commits can be tested automatically, passed through static code analysis, and deployed to relevant environments quickly. Thanks to these frequent commits, software developers continuously integrate their developments. Thus, conflict problems seen in long-term feature branch developments are eliminated. Developers do not have to spend time-solving conflicts.
When a feature branch-based development technique is adopted instead of Trunk-Based Development, this feedback mechanism slows down, since the developers make long periods of development on the branches they have created for the relevant features, but when they merge to branches such as development or master after the development is finished, the relevant CI processes will start, and this is definitely an undesirable situation.
Docker container images should be created on a single branch in the ideal world and this image should be used in all environments. Trunk-Based Development is again an ideal use for this situation. All environment-based changes should be managed with environment variables. Database information in test environment and production environment must be changed via an environment variable. Using the feature toggle technique, some unfinished features can be left open to the user in the test environment, but all feature toggles that can be turned off in the live environment must be managed with environment variables.
See you in next article…
