Showing posts from August, 2017

Meaningful Versions with Continuous Everything

Q: How should I version my software? A: Automated! All continuous delivery processes follow the same basic pattern: Engineers working on source code, configuration or other content commit their work into a git repository (or another version control system, git is used here as an example). A build system is triggered with the new git commit revision and creates binary and deployment artefacts and also applies the deployments. Although this pattern exists in many different flavors, at the core it is always the same concept. When we think about creating a version string the following requirements apply: Every change in any of the involved repositories or systems must l ead to a new version to ensure traceability of changes. A new version must be sorted lexicographically after all previous versions to ensure reliable updates. Versions must be independent of the process execution times  (e.g. in the case of overlapping builds) to ensure a strict ordering of the artefact

Favor Dependencies over Includes

Most deployment tools support dependencies or includes or even both. In most cases one should use dependencies and not includes — here is why. Includes work on the implementation level and dependencies work at the level of functionality. As we strive to modularize everything, dependencies have the benefit of separating between the implementations while includes actually couple the implementations. Dependencies work by providing an interface of functionality that the users can rely upon - even if the implementation changes over time. They also create an abstraction layer (the dependency tree) that can be used to describe a large system of components via a short list of names and their dependencies. Dependencies therefore allow us to focus on smaller building blocks without worrying much about the other parts. To conclude, please use dependencies if possible. They will give you a clean and maintainable system design.