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!
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.