Why adopting a git standard makes for better code

Managing software can be a complex endeavor when dealing with multiple developers in multiple teams over multiple projects. As an aid to successfully handle projects of different sizes on a technical level, Dropsolid created standards that allow for flexibility, while also being robust.

The importance of team alignment

With the growth of the development teams at Dropsolid, there was a combination of existing approaches and an influx of insights and ideas. After a while, some people started noticing little differences in the way the teams were operating. Even within a team, there were small variations between projects. This caused confusion, which we want to avoid. Since every team has a representative in the QA guild, which brings together people with a shared interest for quality assurance every so often, we decided that those meetings would be the right place for tackling this issue.

On a mission to improve our guidelines

As a first step, the guild looked towards existing Git standards and the general best practices of how to test code and functionality. We started from the current guidelines and supplemented them with fresh ideas from different people, eventually leading to a new and improved guideline.

This result was presented at an internal dev meeting, to explain why having uniform, but adaptable Git standards are so important and to address the potential concerns surrounding these new standards. Afterward, the teams had some time to let it sink in and give feedback. This led to some final alterations and made it even better. In the end, we’re confident that we have a guideline that everyone understands and fully supports because our teams are aware of why choices were made. It cannot be understated how important that is.

The guideline touches upon several topics in handling software development. Without going into too much detail, here is a list of the key points:

• A workflow that covers all use cases.
• The possibility to deviate from the standards if needed, after discussing this within the team and after the sign-off of the team’s architect.
• A single source of truth is the main branch, which equals the production environment.
• Several supporting branches that all have their use case:
  • Integration branches are used for finished functionality and are coupled with an environment. They can be recreated at any point in time.
  • Feature branches are used to develop new features and are also used for code reviews and other QA checks.
  • Epic branches are used for “bundling” user stories and bug fixes with shared business value together.
  • Child branches have the corresponding epic number in them so they are easily distinguished.
  • Release branches are used when more than one feature is deployed at once: when a separate environment is used for release preparation, or when a customer likes to test several features at once.
  • Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version.
• The use of a standard commit message, which is in line with how GitLab (our main repository platform) operates.
• The importance of code review. It is used to catch issues early and as a learning tool for both the author and the reviewer of the code.

Company-wide impact

Providing these new standards helps developers in their daily work. Because everyone’s way of working is aligned, the cross-team collaboration improved and the onboarding process for new developers runs smoother. Furthermore, since the standard is very solid it should improve the company-wide quality control and overall quality of development projects.

Why this is important for our clients

We care a lot about the needs of our clients allowing them to test at their own speed while keeping the option of releasing items independently. The workflow is important for flexibility because it allows us to do things in parallel. This way we can pick up tickets and solve them, while still waiting for other tickets and more clarification. A customer is able to "pick and choose" what tickets they want in the release, this way of working makes it efficient for both sides, as well the client and their team as our developers.