build management
Build-management is the SCM discipline of assembling a software product out of its source artefacts. To achieve this, the processes of generation, transformation, dependency resolution, verification and packaging are performed. The main objective of this discipline is to build a software product step by step and bottom-up from its many input artefacts, and thereby to generate a complete software product as deliverable units for the deployment-management discipline.
-
Is your build fully automated?
-
What are the fundamental build steps (compilation, packaging, etc.)?
-
What additional steps should you automate (documentation, testing, linting, etc.)?
-
What is your final deliverable product (WAR-file, installer, container image) and how to build it?
-
Is your build reproducable?
For version-identification you should follow these best-practices:
Automate your build-process up to the generation of deliverable units.
Each manual step has to be documented and can be done inaccurate. Further, a general requirement for the build-process is that it is reproducible and potentially even audit-proof. Be lazy and automate!
The build-process is not just the compilation and assembly of some library. For building a full release it starts with checking out the code base and goes up to the generation of the deliverables that are released and finally provided to the customer. Design this process from the start and automate as much as possible.
Integrate unit-tests into the build and do continuous integration (CI).
Create unit tests for your code and have them integrated into the build-process. Then use a tool for continuous integration that watches your source code repository and performs a build after changes have been committed. This should apply for all branches - not only the mainline but especially also feature-branches. Only merge feature-branches after CI ensured a successful build. If something gets broken, the continuous integration sends a notification to according persons in the team.
Build software systems hierarchically step-by-step and bottom-up from smaller lower-level input artefacts to larger higher-level output artefacts. Furthermore, your repository structure should reflect this hierarchy.
Explicitly track and resolve the transitive build-time dependencies between artefacts to ensure a transparent and traceable build result.
Even average-sized software systems have extensive build-time dependencies between their contained artefacts, especially those generated by frequently-used third-party libraries and frameworks. Hence, it is imperative to explicitly track and transitively resolve all those dependencies during the hierarchical artefact building process. Common build-tools will automate this process. You get the most power if your tool supports transitive resolution of dependencies. However, tiny mistakes in the dependencies of your own or third party artefacts can cause unexpected results. E.g. if you update the version of a third party artefact the new version might weave in new dependencies that are undesired but would be build into your product. Therefore, track your dependency tree whenever dependencies change.
With this approach, the build is completely transparent and therefore traceable. Additionally, only in this manner an automated build procedure can safely resume a build at any step and (re)build the necessary artefacts only. Finally, this also allows the license compatibility check and vulnerability check.
Try to perform as many sanity checks and transformations as possible during build-time. Do not inadvertently delay them until run-time.
Whatever you can do during build-time should not be delayed until run-time. Hence, you should use the build-time period to conduct as many sanity checks and transformations as you can.
For instance, during build-time, try to pre-validate your configuration (e.g. XML,JSON,YAML) and code files (e.g. sonarqube, ts-lint, shell-check), and to format-transform and generate artefacts (e.g. image, localization and internationalization data).
Bundle your domain artefacts in accordance with domain specifics in the architecture and the expected change frequency.
In order to optimally support test and the build & deployment always try to bundle your build-time artefacts in accordance both with your architecture’s domain specifics and the expected change frequency of the artefacts.
For instance, if your architecture contains a domain-specific subsystem, ensure that it is available as a separate build artefact in order to allow it to be easily tested separately. And if two artefacts have two completely different change frequencies during Implementation or even Operations, it is advisable to keep them separate. All platform-specific sections should also be bundled separately.
Keep the deliverables of your software product free of any environment specific configuration.
Separate environment specific configurations from configuration-packages and keep your software-packages portable. This allows building of software-packages only once and then deploying them to different environments for development, testing, acceptance, and production. This will guarantee that the software going live has been properly tested.
The environment specific configurations can also be bundled as packages per target environment.
More fine-grained recommendations or best-practices for specific build tools and technologies can be found in build specific recommendations.
This documentation is licensed under the Creative Commons License (Attribution-NoDerivatives 4.0 International).
