How do your developers build the software that your company sells? Do your developers manually build every version on their machines, or do they use a dedicated build system? If you don't know, ask your development manager to show you the latest build on the build system. If they're not sure, ask one of your senior developers; ideally their answer will be something like "Which build server do you want to see?".
If they can't show you the build system, ask them whether they're using Continuous Integration, or CI, to build the software. If they're not, ask them why not; bear in mind there is NO right answer to this question!
If everyone avoids your questions, it's time to be suspicious. If you ask for the latest build and anyone says they'll "Run you off a copy," or, my personal favourite, "Set off a build later today," then there is almost certainly no automated build.
By now you may be asking why build systems are so important, and what's wrong with just building software and/or manually assembling scripts on your machine when you're ready to send it to test. The main reasons are:
- Automatically building reliable software requires a consistent configuration on a build machine. This gives you a repeatable, consistent build which changes when your developers actively change it, not when some random update occurs on a development machine somewhere.
- Builds are automatically triggered whenever there are changes made to the source code in your version control system. If the build fails, this makes it much easier to identify the changes responsible, and fix the problem.
- Every build is "clean", in that there are no left-over artefacts from previous builds to cause problems with the new builds.
- By their very nature, developers try out new open source and free software on their machines. Most of this is deleted but some may get linked into your software, creating licensing problems you won't know about until it's too late. A build server with known software on it avoids this problem.
The build server forms the basis of your entire continuous integration / continuous deployment (CI/CD) process. Initially at the end of the build process the build server should produce installation and deployment packages ready for testing or deployment. Once this is working, you can concentrate on automating the rest of your testing and deployment processes.
There are many ways to implement build servers; Jenkins and Team City are both good build systems, although others are available as well. If you don't have any spare servers, create one as a virtual machine. Assuming you're not building a large number of systems yet, the build server doesn't need to be a hugely powerful one. A couple of CPU cores should do to begin with, but make sure it has a reasonable amount of RAM, and plenty of disk space to store the output. You can always upgrade the server later. Some of the more popular build systems are described below:
| Name | Build Process Language | Notes |
| Jenkins | Groovy | |
| Team City | Custom | Usually runs on a local server. The build definition is stored separately from the source files. |
| GitLabs | YAML | Usually cloud based, but can be locally hosted. |
| Amazon CodeBuild | YAML | Paid cloud service, part of AWS, but only chargeable when builds are actually running. |
When you start moving towards using Continuous Integration you may encounter people who don't believe that automating the build process is worth the effort. These people seem to feel that systems are best produced manually, and often go further and advocate manually installing the software, and even manually testing it. This approach is wrong in several ways, not least because any sort of manual process introduces delays and the risk of errors. After all people make mistakes, computers do not. Another thing to note is that the people advocating that the developers and testers do all this manual work are rarely developers or testers, yet they feel they know better than either how to develop software.
Remember: beer, wine, cheese and bread all benefit from being manually-created artisanal products. Software does not. The very things that make food and drink tasteless and anodyne are the things that help make software reliable.
