Configuration management is often considered as a synonym for SCM systems (Software Configuration Management, Source Configuration Management, Source Code Management). However, it is much more than only your revision control system. CM, at the least, includes managing:
- configuration of your application on your local, test, staging and production environments (and whatever else you have),
- your build process – Maven, Gradle, Sbt or Ant and how they are integrated with your software production process,
- software development processes in overall,
- change identification in your application – distinguishing between different software baselines, bug tracking, etc,
- hardware configuration of your all environments.
The book Continuous Delivery provides us a nice, compact and comprehensive definition:
Configuration management refers to the process by which all artifacts relevant to your project, and the relationships between them, are stored, retrieved, uniquely identified, and modified.
The first step to do it properly is storing everything in version control. Do you think this advice is silly? If so, you have missed the word: everything! It is advised to store in a SCM system your whole build system, test environments configuration, installation and deployment scripts, OS configuring scripts, CI configuration, and so on. Every piece of text file that is part of your development process should be stored in some SCM system, and used from that location. While such an approach is sometimes a little harder to maintain, the benefits that it brings are enormous. Properly introduced it allows you to track each change within any piece of infrastructure you own, troubleshoot problems much faster and more easily return to previous versions. You will no longer be in a situation when one of critical servers fails and no one knows how to replicate it.
The next step after using SCM system is using it properly! One of the main rules is to integrate changes as often as possible to your main branch (usually master or trunk). You should commit to it at least once a day or even several times a day. It is easier to test such changes, it is less likely to break the application and it is also easier to revert it. It also allows us to track all changes in detail. Imagine that you are inspecting written code two years from today. It will be much more convenient to have small changes with proper comments than one big three week development branch.
While mentioning often committing we cannot omit a topic of commit messages. If you were not sitting in a cave for the last 10 years, you have probably heard it hundreds of times:
Use meaningful commit messages!
Proper and meaningful commit messages are critical for the right Configuration Management. Thanks to them it is much easier to identify why a change was introduced. Debugging, inspecting history, detecting bugs and many other activities are much easier when you are able to really know what each commit is about. A great practice is to add to each commit message a ticket/task/issue identifier related to the task you are working on.
If you are using SCM system for all parts of your development ecosystem in a proper way, consider if you are managing your components and dependencies in a controlled manner. While you can implement such a system from scratch, I highly recommend you to use one of the build systems that offer it out of the box. Great examples are Maven and Gradle. You can quite easily define several projects and dependencies between them. Both systems allow you to deploy easily consecutive versions to artifacts repository. You can also instantly make your project dependent almost on any java open source library.
So we store everything in SCM systems, we also have in place build system managing projects and their dependencies. The next step is to handle your application configuration in a clean and robust way. The great practice is to have all configuration defined in one place, the best if we are able to clearly distinguish between configuration options and an instance of the configuration itself. Thanks to such distinction we should be able to easily commit several configuration types to our SCM system and use the one most suited for current needs: development, CI, smoke tests, pre production tests, staging, etc. Do not forget, that the application should also always obtain the configuration in the same manner.
Having properly managed application configuration allows us to implement proper environment management. If we would add to it full deployment automation and storing everything in SCM systems, we are able to build an ecosystem where each, literally each change related to the environment is reflected in the repositories history, easy to track and simple to revert.
This is more or less a sketch of Configuration Management. The whole topic is mainly about management of all changes related to the project, including the configuration of the application itself. Properly implemented it allows us to introduce an organization process of handling all modifications in a controlled manner. Moreover, proper Configuration Management is the first step to implementing reliable Continuous Integration systems and as a result is also a prerequisite for Continuous Delivery implementation.