There are many different patterns how to use SVN and many approaches how to maintain the code during the various phases of project life. We have several applications on our platform which are using similar branching model to make the release process clean and which helps us maintain the code easily. This model is not strictly fixed as the environment around us is changing and we need to update our processes according to new challenges.
During the time, we moved from very easy system to the complex one which allow us to release projects independently and support bufixing of the production code at the same time.
Alongside the model and the processes, there are few basic rules which are very useful to keep the SVN repositories clean and easy to maintain.
Tags - For each release is very useful to have a tag with clear version number and changelog.
One commit per feature - The commits should contain only one feature/bug-fix and also the feature should be in one commit. This helps a lot during the merges and keep the SVN log easy to read.
Naming convention - Thing which can save your time during the night, when you are trying to find a bug on production.
One process used by everyone - Try to create the process clear as possible for everyone and agree with the team, how the tags, releases, merges etc. will be done. This is critical must for the successful support of the production code.
Old branching model
Each branching model has different purpose and reflect the team and environment where it is maintained. One of the first model used on our applications was mainly focused on production code as the teams had limited resources and were supposed to do a release with tents of commits to the UAT and PROD environment each week. Also, there were many bugfixes from the UAT testing and they needed to be released very quickly. From these reasons there was no time to merge all tasks to some dedicated branch or to create the test branches and keep them clean. The solution was to use tags, what is in fact anti-pattern, but it worked for several years.
The main goal was to keep production code separated from the development, as the trunk were usually unstable. The tags were created mainly from the last production tag and only changes tested on UAT were merged to the new tag. Time to time when some big project or feature come, the trunk was copied to the new branch and development was done only in this special branch. Critical part was to keep this branch synchronized with the trunk at least on weekly basis. This allows us to maintain the production code in parallel with the new code. At the end of the project the feature branch was merged to the trunk or replaced trunk. Commits not merged to the feature branch were handled later. This guaranteed smooth release as the changes in the old trunk did not affected the project just before the release phase.
Very simple for beginners
Quick releases from trunk to production
Commits into tags
Production code can be different from trunk
New branching model
New branching model was focused mainly to keep the log readable and to not change the tags during the time. Enabler for this process was increased code quality and introducing maintainer role. This Person was responsible for the merging the changes into appropriate branch and prepare release tags.
The main change was in introduction of the branches per environment and strictly separated, unchanging tags. The task from the trunk was merged into the UAT branch and in case of multiple commits for one bugfix (this was more common than we expect) they can be merged as single commit. This process cleared the log of the branch and showed content of each commit. After successful test on UAT, the change was merged to production branch and then tagged into production version. The features or projects were done in similar way like before but the branch was created by tagging the production code and after development phase replaced trunk. This was done mainly to keep the trunk aligned with the production.
Very robust and stable
Clear visibility which changes are deployed on environments
Trunk synchronized with production after each project
Complicated for beginners
Require maintainer role or someone who is responsible for the repository
Release process require more steps
More Feature / Project branches
Very often we developing more features in parallel and again, there are many patterns. For our purpose we are using following schema which allows us to keep all branches synchronized and refresh the trunk after each feature release. In our context the feature is developed for one or two months, so overhead with the replacing of the trunk and creating the branches is not huge. The features needs to be planned in advance to keep the order of the releases, because features contains all previous development.
Journey is the goal
As we mentioned earlier, there are many patterns how to keep your code and you should never stop trying to improve your process. Our current situation pushed us to review our branching model and we are just finishing completely new model. As soon as we implement it successfully to all repositories, we will share it with you. Stay tuned!