Skip to Main Content

How we develop Software Part 1: Version Control

We've been working on and with the Internet for many years, and we've been helping to shape it for almost as long. Much of what we take for granted today was not so long ago - and if you go back more than a few years, you'll find that the process of creating a website has changed massively.

Now, every agency has certainly found its way to deal with this issue, and fortunately, industry standards have evolved as well. With this series of articles I would like to present our way and also try to strengthen the understanding between all project participants - because only together something really good can be created. 

First of all, I would like to postulate some prerequisites that we can probably easily agree on in any major project: 

  • We would like to have the website in a state at all times that we can quickly and safely apply updates. 
  • Functionality that is in use on the website will not be broken by a change elsewhere.
  • We ensure that we can restore a previous state of the website at any time. 
  • We make changes to the website available for acceptance in isolation, without compromising the integrity of the LIVE instance
  • We may withhold individual changes, and play out others. At no time may the website be blocked by unreleased changes. 

This sounds quite simple and self-evident; unfortunately, it is neither one nor the other. There are solutions for all these requirements. This series of articles highlights our way of dealing with them. 

As with development itself, there are several parts that need to mesh together. In order not to go beyond the scope of our blog posts, we will divide them into individual topics. In the first article of this small series, I start with what I consider to be a completely indispensable basic requirement for any software project: the use of a version management system!

Basic Re­quire­ment: we put our Code under Version Control

This should indeed be standard for many years; from experience with the one or other project we have taken on, we unfortunately have to say: it is not. And I would like to give everyone the urgent advice: Make sure that the executing agency uses such basic software management tools; if it already fails here, there is often much more wrong. 

Our version management system allows us to keep track of changes as the project progresses. It allows us to easily keep track of who added or changed code, when, and for what reason. And we can restore any previous state. 

In our version management, we always have several so-called branches. In the live branch is the state of the website, which is currently deployed on the production environment. In so-called issue branches we further develop the website or fix a bug. For each ticket that customers create in our system, a developer creates a corresponding branch. Once the work is done, passed through internal QA and finally accepted by the customer, the issue branch is reintegrated. 

Working with issue branches allows us to resolve the dependencies of changes. Often a change request is stuck in the release process at the customer and is supposed to be overtaken by others - all this is no problem for us. 

Only with a well-maintained version management system is it at all possible to work unproblematically with several developers on the same project. And in the context of internal QA, a second opinion in the form of a code review is essential, especially in the case of far-reaching code changes; the version control system shows exactly which code should be submitted to the main branch. A second developer can provide valuable advice here on how to optimize the solution presented. This benefits the developer, because he gets direct feedback and suggestions for improving his code; the reviewer, because he can naturally learn something from the presented solution; and the product itself, because only reviewed code is added. By the way, developing code and reviewing it does not follow a hierarchy: it is not uncommon for junior developers to review code from senior colleagues and have comments on it. For us, this is a valuable contribution to internal knowledge transfer, in all directions.

By the way, we use git as our version control system and Gitlab as a tool for our reviews (and for our build chains, which we will discuss in part 3 of this series).

In the next part of this article series, we'll use the conditions we've just created to get projects up and running quickly on our development machines.