#17: The Ultimate Repository Configuration
DevTower Weekly
Just renamed From Junior to CTO Weekly Thoughts to DevTower Weekly
fjtc.substack.com → devtower.substack.com
The Ultimate Software Engineering requires us to follow some rules, and leaving their maintenance without control will lead to increasing entropy. The more rules we define, the more difficult it is to support them manually. In this issue, we will summarize the configuration to maintain already known pieces of the ultimate software engineering and automation of that maintenance.
As before, my experience mainly relates to Gitlab, so some things might not work on other platforms.
How Gitlab helps to configure
The Ultimate Commit, The Ultimate Contribution, and The Ultimate Code Review require you to form your commit messages according to Conventional Commits spec. Additionally, branches should be named after tickets, approvals must be given before merging, etc. So many rules. Let’s check what opportunities we have to manage these constraints.
It is highly recommended to read the mentioned posts before this one.
Push rules
It is important to say that even though push rules are amazing, they are available only on the Premium Gitlab subscription. I won’t sell GitLab here, but this advantage makes sense.
I’ve already described push rules usage before in The Ultimate Contribution post. So, read it there. You can also review the docs available here.
Approval Process
An approval process is available in all versions of GitLab, but for the free one, it is not flexible. Greater plans provide the opportunity to use code owners or manually configure approvers.
Another important setting available for approvals is Settings > Merge requests > Merge request approvals > Approval settings > [Unset] Remove all approvals. In The Ultimate Code Review I described why it is important to improve collaboration.
Additionally, you could disable emojis because the approval process is in place, but it is not necessary (Settings / General / Visibility, project features, permissions)
Repository Restrictions
Protected branches do not allow you to push changes directly. That is a great constraint that simplifies the process and does not allow unexpected changes to be delivered. The default branch is used as a default target for Merge Requests. Use the following sections to manage:
Settings / Respository / Branch defaults
Settings / Respository / Protected branches
Merge Requests
To get a properly working git history, it is important to configure merge requests. You can find settings at:
Settings / Merge Requests
Configure the merge method. We discussed that merge commit gives you more flexibility than fast-forward or semi-linear. There is a property in place.
Thanks to conventional commits spec, every commit matters, so you should disable squashing as a possible action via UI. If developers decide to squash some commits because of the wrong decomposition, they should do it manually.
Threads help to control how many open questions there are. You can have an agreement with your team that a developer resolves threads only if a reviewer explicitly asks them on the last comments. Otherwise, merge requests cannot be finished. Something similar we have for pipelines. If your pipeline doesn’t work, it likely won’t work on the default branch. So, protect yourself and do not allow merge unsuccessful pipelines.
Configuration as a Code
Maintenance of all these configurations is pretty hard everywhere. Otherwise, it is not guaranteed that these rules are satisfied. In my practice, I saw how teams created their own job that ensures configuration according to the committed config, but instead of writing your custom job that works with GitLab API, you could try:
https://gitlabform.github.io/gitlabform/
I did not use this tool, but it looks similar to our in-house solution.
Conclusion
Simple rules should be satisfied to make the development process solid and reliable. Modern VCS hosting helps to control these rules, but that might require advanced plans. You can avoid manually maintaining these options by using configuration as a code solution.
The Ultimate Software Engineering Series
The Ultimate Software Engineering topic is not exhausted yet. I need to summarise some ideas to accurately deliver them as well as publish already described ones wider. So, the next issue won’t be dedicated to another topic inside the idea but rather some other considerations, practices, and practical advice. Subscribe so as not to miss
