In Deveo 2.9.0 we have a new feature called protected branches. Protected branches offer better control over changes made to different branches in version control systems. Protected branches enable more assurance to development teams that the mainline of their precious source code is secure as well as allowing better workflows within teams to emerge. We implemented the functionality to cover Git repositories first, but since Deveo supports three different version control systems: Git, Mercurial and Subversion, we are going to add the support to Mercurial and Subversion later.
Why protecting branches is essential?
In large organizations where development teams might span across multiple locations, you need to be hundred percent sure that you always have your software in shippable state. We at Deveo have heard numerous horror stories of development teams having their trunk / master constantly being full of buggy code, because there's no control over who can do what. The wild west might be appropriate metaphor for such situation.
There's even a more extreme example of what might happen when you don't have control over who can push changes to what branches in Git. One well known example is the infamous incident causing over 180 repositories containing Jenkins plugins' code to roll back over a week full of work, because of misconfigured Gerrit replication configuration.
Apart from the governance and safety point of view, protected branches allow quality gate like workflows to be enforced within development teams. This could mean for example that development teams can have their senior developers accept changes from rest of the team members. This supports distributed development teams and workflows as well as quality assurance for subcontracting work.
How this differs from typical fork and pull-request workflow utilized heavily for example by Github and the open source community, is that protected branches allow the control to be within the same repository. This means in practice that individual developers no longer need to maintain their forks, nor does the visibility disappear from the rest of the development team, as the development branches reside in the same repository.
External contributions are typical in open source projects, and there a fork and pull-request workflow is a great way to give external collaborators a place to work. However in enterprise world, the common case is to work towards a shared goal within a team sharing one or multiple own repositories. Also even when utilizing external collaborators, we typically want to know what they are doing.
How protected branches work?
If you wish to skip reading and only want to see how things work, check out the Youtube video below:
In Deveo we try to maintain a healthy balance between simplicity and enterprise requirements, thus selecting the most seamless way to bring protected branches to our users was our intention. In the picture below you can see the feature in its simplicity.
To enable protected branches one can simply open repository settings from the repository browser, and either protect or unprotect desired branches. Once a branch is being protected, Deveo ensures three different things:
- All forced pushes to the branch are rejected
- Deletion of the branch is prohibited
- Non-admin users may not push changes to the branch
All forced pushes to the branch are rejected
Git allows a --force switch to be used when using its push command. Force push is used for overwriting the data in the remote repository. We typically want to overwrite the data when we want to change the history. However changing the history is mainly useful in two occasions:
- when you haven't yet pushed your changes to any shared repository, or
- when you are working alone
In the first case, which means basically using git rebase, or commit --amend, the changes in history don't affect other developers nor the remote repository in question as they are done locally, without needing a forced push. The second case rarely happens when working within a team or shared code base in general.
In Deveo protecting a branch rejects all "push --force" events from all team members. Not even a project administrator nor company admin are allowed to execute it. As a sidenote it's worth mentioning that this kind of behaviour would have prevented the earlier mentioned Jenkins plugin disaster.
Deletion of the branch is prohibited
Similarly as preventing rewriting the history, protected branches prevent deletion of the branch. This will ensure that for example the master branch won't get deleted by a mistake. Preventing the deletion makes it also easier to see which branches are static, and used for example to mark releases, while feature branches can lie unprotected.
Non-admin users may not push changes to the branch
The last functionality of protecting a branch, is that no other users than project administrators are able to push changes to the branch. This ensures, that the master or release branches stay clean and only selected few can control what goes there. It will allow quality gate like workflows to ensure where senior developers can review and merge changes to the mainline or push completed features to release branches.
In retrospect there would have been multiple ways to how protection of branches could have been implemented. Solutions such as Assembla offers the possibility to map which users are able to push changes to which branch. Gitolite and Teamforge on the other hand go even a step further and allows multi layered permission schemes by defining permissions both in repository level as well as branch level and even in file level.
We chose our solution by thinking the ease of use and understanding the needs of our end users. We have been unfortunate to witness many great tools simply taking too much time to set up, maintain and manage. We know our solution fills 95% of the use cases, while in the same time offers intuitive user experience.
Wan't to try the new functionality out? Request a free 45 days trial here.
What's up in the future?
Stay tuned during the spring for other features coming up! We have quite a lot of nice things coming up, such as the code review functionality, as well as other smaller improvements.