Configuration Management – In this post, I will just conclude some principles in CM.
“Configuration management (CM) is a process for establishing and maintaining consistency of a product’s performance, functional and physical attributes with its requirements, design and operational information throughout its life. ”
Below is the checklist you can use to check whether you have adopted the CM in your team or not and you should “YES” to all the question:
1. Can you reproduce any of your environments – Build, Test, Staging, and Deploy, etc. including OS versions, patchings, networking configuration, technologies stacks, and other software applications and setting deployed upon your environmnets?
2. Can you easily deploy your new changes into your environments in an incremental manner?
3. All your changes in configuration could be tracked?
4. All of the CM rules/policies can be conducted strictly?
5. Is it that anyone from development team, testing team, PMs, etc. can easily visit these CM information?
6. Will your CM strategies delay the software delivery?
One of the essential elements of CM is Reproducible. So deploying a Version Control System in your organization is a MUST. There are lots of Version Conrol Tools. Like RCS (Revision Control SYSTEM) shipped with Linux, CVS (Concurrent Versions Control), SVN (Subversion), and Perforce, etc. In this article I will not compare their advantages or disadvantages. But my recommend is, if your team wants to use commercial product, then Perforce will be your choice. If your team wants to use opensource products, I strongly recommend SVN than CVS.
Version control all you have
Here the term ‘Version Control’ is not the same as ‘Source Control’ as Version Control is not merely for Source Control only. In my opinion, all of the artifacts related to your developments should be under version control. Development codes, testing codes, database scripts, build/deploy scripts, documentations, libraries files, and all of the configuration files, even compilers and tools should be under version control. In this way, it will help new team memmbers join your team easily.
Commit code frequently into mainline
When adopt Version control, there are two principles. Firstly, you should commit codes very frequently so you can find out the build errors supposed you have check-in builds and then you can roll back to the last working version. Secondly, your team members can see what you changed and they can work based on your latest changes.
In some of the development teams, they will create branch to do their developments however that will cause below problems,
1. It is breaking the Continuous Integration principles. As in CI, it requires that we should integrate ASAP and working with branch will delay the integration.
2. It is difficult to merge those branches together if they go too far.
3. It is difficult to do code refactoring.
So, we should commit code frequently and commit them into mainline.
Have meaning comments when commits code
All of your commit should give them a making sense comments. Like, “This commit is for bug#123456, and it would introduce method getId();”. It is humanity to give your commit a meaning comment.
In a SDLC, the most common dependencies are 3rd-parties libraries and the dependencies introduced by those 3rd-parties.
Those libraries usually exist with binary files, like a junit.jar, unless you are using interpreting languages. Actually there is argument that whether we should have those libraries under version control. My suggestion is that we should also have version control for those libraries. Yes it is true that you can download them from internet if you want to deploy a new environment and those libraries basically will not get changed. But let’s consider scenario: Your project is using a 3rd-party library ABC-3.2.1.jar from http://repository.abc.com however due to an update in ABC-3.2.1.jar (Version 2), then your configuration will get updated automatically and it will break your build or introduce potential problems. Maven provides a powerful in dependencies management and it will help you save a copy locally as local repository if you configure it works like that.
Modules mean your internal projects. Supposed you are using Maven as the Build Management tool, then all of your internal projects can be deployed into the local repository as a module.
Software Configuration Management
As a critical component, configuration information work together with product code and its data to build the applications. We can control the build, deployment, and live of a software product via configuration information. A delivery team should consider seriously how to configure those information and how to manage them during the full of SDLC.
Configuration VS. Flexibility
Everyone wants to have the highest flexibility but sometimes we just can not have all of the good things in the same time. We need to sacrifice part of the flexibility for a better product quality. The risk of changing in configuration management is lower than changing codes. Supposed that development has its highest flexibility then all of the configuraiton information will be stored in the source codes and any changes will cause a change in source code. That is too much.
We can configure system during its processes of build, deployment, testing, and publish. Below is the categories list of configuration information:
1. Configuration information for building software into binary.
2. Configuration information for packaging into a war, ear, etc.
3. Configuration information for deploying software.
4. Configuration information for starting up/running the software.
Principles of Configuration management
We should treat configuration information the same as source code, manage them properly and test them. Below are some points we need to consider,
1. When and what configuration setting we can introduce during a SDLC? For example, for the setting of junit.jar, we should introduce them only in testing phase; for JDBC pool setting, we should have different setting during different phases (like System Testing and Production).
2. All of the configuration information should be stored in the same repository as source code but the detailed information should be stored in a different place. User passwords, web console passwords should not be sourced control for safety.
3. The instantiation of a configuration file should be automated.
4. There should be a naming convention for all of the configuration settings.
5. DRY (Don’t Repeat Yourself). Just ensure that every configuration item works for a special purpose and there are no duplicated item with the same purpose.
We can utilize Virutalization Technologies to do environment management. In my current company, we are using Oracle VM to templatize any environments and it can provide a duplicated environment just in a click. All of the changes in the environment can be tracked.
Configuration is the basic requirement to do Continuous Integration, delivery management. We should version control of everything required to build the software. Of course, we need to balance between Flexible and Configuration (I will have a post later to introduce Maven’s Convention over Configuration.).