Working on different applications across different companies, you will come across multiple problem cases regarding how to manage your application code to allow good documentation, accountability and iterations of what you are developing and what you are releasing. In all cases, there is something unique that works for you even though the best practices can be chalked down to simpler, boarder categories.
There are three major factors that need to be taken into account when deciding what kind of flow you would want in your Git repository. There are enterprise and personal options available like Github, Bitbucket etc. Both of them have the minimum features to support the categorical approaches based on the three major factors outlines below.
Number of contributors
The more the contributors, the more complex and difficult to make sure everyone is able to develop and release it in a hassle free manner. It is possible for contributors to often encounter merge conflicts when deciding to send code to production. Even though tedious to fix, this also leaves a looming danger of incorrect code being pushed. It adds a need to have a dedicated release manager to take care of the code development cycle. No one wants that to happen.
WebServer vs. Mobile
The situation changes drastically when looking upon how mobile applications are developed. It is needless to say that for any organisation, the number of releases for mobile applications are far lesser than the web server code. For a web server, it most likely is possible to release whenever there is a need, hence smaller code snippets can be sent live instead of grouping them. For a mobile app, the opposite is true. More compact and larger releases are sent (apart from bug fixes of course) and there needs to be a co-ordinated compilation of code from various contributors to be packaged and sent to production.
Organisation structure
When an organisation has a flat structure where almost everyone is contributing to almost all modules developed and also everyone is responsible for testing the applications, then it becomes easy to co-ordinate and plan for releases. However, in organisations where the teams and their roles are divided and there are boundaries, there the task becomes really difficult. Part of that complication is due to limited number of testing environments and too many things get queued up in the release chain, especially if the QA team is too small as compared to the number of developers.
The more the contributors, the more complex and difficult to make sure everyone is able to develop and release it in a hassle free manner. It is possible for contributors to often encounter merge conflicts when deciding to send code to production. Even though tedious to fix, this also leaves a looming danger of incorrect code being pushed. It adds a need to have a dedicated release manager to take care of the code development cycle. No one wants that to happen.
WebServer vs. Mobile
The situation changes drastically when looking upon how mobile applications are developed. It is needless to say that for any organisation, the number of releases for mobile applications are far lesser than the web server code. For a web server, it most likely is possible to release whenever there is a need, hence smaller code snippets can be sent live instead of grouping them. For a mobile app, the opposite is true. More compact and larger releases are sent (apart from bug fixes of course) and there needs to be a co-ordinated compilation of code from various contributors to be packaged and sent to production.
Organisation structure
When an organisation has a flat structure where almost everyone is contributing to almost all modules developed and also everyone is responsible for testing the applications, then it becomes easy to co-ordinate and plan for releases. However, in organisations where the teams and their roles are divided and there are boundaries, there the task becomes really difficult. Part of that complication is due to limited number of testing environments and too many things get queued up in the release chain, especially if the QA team is too small as compared to the number of developers.
Keeping these factors in mind, there are three broad categories in which the code contribution, testing and release can be planned.
Fork & Pull Model
All developers fork the main repository. The main repository (a.k.a parent) holds only production code branch (master), a cumulative development branch (develop) and release branches. In organisations where there are a multitude of developers but not a frequent release cycle, there can be just a single release branch. Developers keep their developments in their own forked repositories and merge it to the release branch only after it is planned for the next release. This is done by raising pull requests to the release branch in the parent. This helps in isolated code review and adds better accountability and documentation of each change that goes live. The code is also merged to develop as and when it is completed for other developers to build on top of. In an organisation with a frequent release cycle, there can be multiple release branches. Usually, the release branches are limited to the number of parallel QA tasks that can be run. Release branches are what the testers would deploy and test. The release happens after merging to master or before, depending on the bug introduction rate.
Multi-branch model
While the first model will work well with web servers where releases can be frequent and the released code goes out to serve all users, it may not apply to mobile app development. Since the releases are lesser in number, the bug introduction rate also needs to be low and more rigorous testing is required. Also, in mobile apps, it is almost the case where you may be trying different versions of the app on different demographies. Hence, all developers can make their own branches in the main repository and may release their code independent of the code written by the other contributors since it may be a feature that just needs to be released somewhere specific or for some particular audience. This adds an overhead to have a lot of parallel QA processes set up. Unfortunately, that is not always possible. That is why it is mostly encouraged the mobile apps be always in a safe mode, where the basic set of use cases are documented and can be tested by anyone, maybe just by an exchange between two developers. As different versions combine, consolidated branches can be made. There is never really a single production code branch here.
Single branch model
Sometime there are case where your application is a supporting module, which has no functional or business logic in it but support other important applications. Good examples would be deployment configurations or apache/nginx customisations. These also include setups that need not go through QA and are basic changes that are tested if they work. These are not released often and hence are always incremental changes on a single branch, which can most likely be kept as master itself.
Fork & Pull Model
All developers fork the main repository. The main repository (a.k.a parent) holds only production code branch (master), a cumulative development branch (develop) and release branches. In organisations where there are a multitude of developers but not a frequent release cycle, there can be just a single release branch. Developers keep their developments in their own forked repositories and merge it to the release branch only after it is planned for the next release. This is done by raising pull requests to the release branch in the parent. This helps in isolated code review and adds better accountability and documentation of each change that goes live. The code is also merged to develop as and when it is completed for other developers to build on top of. In an organisation with a frequent release cycle, there can be multiple release branches. Usually, the release branches are limited to the number of parallel QA tasks that can be run. Release branches are what the testers would deploy and test. The release happens after merging to master or before, depending on the bug introduction rate.
Multi-branch model
While the first model will work well with web servers where releases can be frequent and the released code goes out to serve all users, it may not apply to mobile app development. Since the releases are lesser in number, the bug introduction rate also needs to be low and more rigorous testing is required. Also, in mobile apps, it is almost the case where you may be trying different versions of the app on different demographies. Hence, all developers can make their own branches in the main repository and may release their code independent of the code written by the other contributors since it may be a feature that just needs to be released somewhere specific or for some particular audience. This adds an overhead to have a lot of parallel QA processes set up. Unfortunately, that is not always possible. That is why it is mostly encouraged the mobile apps be always in a safe mode, where the basic set of use cases are documented and can be tested by anyone, maybe just by an exchange between two developers. As different versions combine, consolidated branches can be made. There is never really a single production code branch here.
Single branch model
Sometime there are case where your application is a supporting module, which has no functional or business logic in it but support other important applications. Good examples would be deployment configurations or apache/nginx customisations. These also include setups that need not go through QA and are basic changes that are tested if they work. These are not released often and hence are always incremental changes on a single branch, which can most likely be kept as master itself.
Apart from the above flows, there are some basic tips that can really help streamline development and release.
- If your application goes through a lot of feature iterations, then keep the test cases for them documented in an ignored directory in the same branch. This way, they move along with the code they test and can really help the testing teams.
- Name your branches correctly. If working on a multi-release branch model, keep the release number in the branch name. On your own forked feature branches, always prefix the name with ‘feature/’. Do the fix with ‘bugfix/’ and ‘cleanup/’.
I hope this post helped you and provided you with what you were looking for. Do submit questions and comments and i would like to help and learn myself.
Comments
Post a Comment