How we develop Software Part 3: Build Chain
Modern software - including websites - consists of numerous software packages. Some of them we develop individually for the current project. For many standard tasks we resort to external code, which helps us to reach the goal quickly and not to reinvent the wheel. Here it is especially important in the course of time which version of which software package was installed - only in the respective combination does the overall software work in the end. To get to grips with this task, there are package managers that resolve dependencies between software packages and keep a record of which versions are active. And via our version management, we can use this to install all software packages at a later date in exactly the version that we need for the current state of our software.
For a modern website to work, quite a few things have to interact. In addition to the software packages needed for functionality, we also have to build, for example, frontend assets (usually CSS and JavaScript) that ensure that the website behaves the way our customers want it to behave in the browser.
Because we want to make sure our application always works, we rebuild the website quite often when changes are made. There's quite a bit that needs to be taken care of and it needs to happen in the right order. For this reason, we have automated this process. This is the build chain.
Through the build chain, we have also ensured that we can assemble the project and all the required packages independently of the developer and the development machine. And we have created an automatism that, whenever a change is made, fully automatically ensures that our project can continue to be assembled afterwards.
This automatism is made to take over other tasks, which may take quite a long time and which we want to be performed on every change:
Coding Guidelines and Software Quality
We work according to coding guidelines and use tests in our build chain to ensure that these are adhered to. This leads to clearer projects and better code.
In addition to static code analysis and linters, we have test suites in place to ensure that the code we produce works and interacts with other components.
Because we automate these tests during build and deployment, we can very quickly detect if something breaks elsewhere during development - before the code makes it to the production environment.
And deliver it please!
Only when we have our code on the target server and everything works, our work is done. Delivering our software to a server is what we call deployment. On the target server, we only want to have software components that are really in use and needed there. By building our application in the build chain, we can copy the result - the finished application - to the target system through simple network protocols that exist on every server. It is obvious to automate the deployment as well. And of course, we did that too, integrating this process into our build chain.
That sounds pretty complicated? At first glance: yes. But let's take a small step back and look at what we have already achieved so far:
We can restore any state of the project from the past, download all components in the version they existed at that time, assemble them and deliver them to any server. Automated.
Our build chain is run centrally through our Gitlab server, every time a developer submits a change into the system. Through frequent automated testing, we find bugs and violations of our coding guidelines right when they occur and can resolve them directly.