Software Configuration Management Planning
So now let's get to the software configuration management planning and lay down a software configuration managment pattern that will enable us to attain the goals previously mentioned here.
First, let's start by answering the following questions...How will you track software changes?
You first need software version control. I have seen bad systems and good systems to manage code changes. A good system should allow developers to address the following issues...- Versioning
- Branching
- Merging
- Release Identification
- Command line interface
- <your favorite IDE> plug in
- Reporting
- History
- Allows pre and post checkin scripts
- Can be used in a multi-site environment (if required)
- Low maintenance
The next section will address several software configuration managment tools out there in the Tools section that will address these issues. Also, over the last 10 years some huge improvements have been made that allow users to download many software configuration management tools absolutely FREE!
How will you track defects and/or enhancements?
Defect and enhancement management has similar criteria to selecting a good version control product. However, there are some additional criteria that should be addressed.- Enhances communication between developers, testers, managment
- Maintains a repeatable process work flow for defects and enhancements
- Easily configurable (fields, db, etc)
- Authentication / Authorization
- Detailed reports
- Low maintenance
- Web interface
- Plugins to <your favorite CM tool>
- Bonus: Plugins to <your favorite IDE>
- Can be used in a multi-site environment (if required)
It should also be noted that there are some monolithic software configuration managment systems out there that combine defect tracking, process work flow, and version control. Most of these systems are expensive high maintenance products that cater to companies that need heavy process. Many of those systems were fine during the 90s, but software configuration management has become increasingly efficient and cheap too! If a salesperson has told you that is the only way to go, please please for the love of everything good continue reading.
How will you know when the current code is broken?
I recommend iterative builds in almost any development environment. Let the chaos occur on the development side, but flush out any issue early in the process. There are several iterative build tools out there that do a fabulous job of communicating the current build status. These tools will be discussed in detail in the tool section.However, for those not familiar with iterative builds let me fill in some details. In the crazy environment of software development you may have numerous developers checking in code at the same time. Developers will step on each others toes. This is the nature of software development. What you do not want to do is to allow this insanity to go beyond the development environment. System testers should not need to understand why developer A cannot coordinate changes with developer B and C.
Iterative builds are the Pavlov response to software design. What you do need to do is when developers start checking in bad code, to send out nasty emails, flash lights, page the development lead, etc. At some point in the not too distant future, it is expected that checking in good code will then be a learned response. For those developers that do not get it, then you have an HR issue :)
How will you manage your environments?
Automation! If there is any one part of this entire process that will make everyone's life easier it is getting everyone on board with automation. Automation is the difference between having happy productive people and burnout and high turnover rates.I have experienced managers that do not care or think automation is a waste of time. What they are really expressing is their devaluation of YOUR time and everyone else involved with supporting the software. If you are in an environment like this, my advice is to run!
An example of an ear file deploy automation...
How will you create a release?
Many version control tools will have different release strategies. These are a means to an end. In the planning stage, it is important to explain how you will identify a release. How the release will be created is often dependent on the version control tool and to some extent the defect management tool that is being used.Here is an example. The following strategy is an example of a versioning strategy that I have used in the past. Your situation may vary, dependent on your environment.
Example: 5.1.3.p1
using the following format...
<major>.<minor>.<scheduled
patch release>.<emergency patch release>
In this example, from left to right, the first digit is the major release number. This number is usually incremented when major functionality is released. The minor release is for adding scheduled functionality less significant than major release functionality. The third is for scheduled releases that address defects. Last, the emergency patch release is for quick fixes that have to get out.
If you have significant customer specific "branding" in the code you may also want signify that in the release number as well. I have seen this sometimes as a prefix to the release number.
How will you manage your people?
This is the area that is not black and white. You as a software professional need to learn how to deal with co-workers, managers, support personnel, skilled employees, bad employees, etc. Here is some advice on how to manage and contain your users, so that all of the groups involved still go home happy at the end of the day.Also, consider the next section on different design process models and how this affects the software configuration strategies that will be mentioned below.
Branch / Merges
Another method for containing development efforts, managing experiments, and providing isolation to specific developers is the use of branches and the merge process. Most version control tools worth their salt will support branching and merging. This should be used often whenever parallel development efforts are needed. Once the changes can be verified independent of the main line of development, the changes should be merged back in a controlled manner. It is key to put this method in a developer's tool box, and allows a lot of flexibility in controlling the chaos of a large development environment.Service Agreements
Service Level Agreements are key between testers, SCMs, developers, and managers. What this does is set out to explain and manage expectations between groups. This can be detailed, but I find that it is easier to explain later if these are as simple as possible.An example of a service level agreement at my current contract, is that the SCM group has asked development to create two scripts to facilitate automation. These scripts include a build.sh to run ant/maven/make and an install.sh that will install the code. This is a good place to separate, because what it essentially says is that developers need to be provide enough information for the support team to be able to build and install the software. Your environment may be different, but you may ask that all build requests after 5PM go to Bob, or daily deploys occur at 10AM and code must be committed by 9:30AM.
Good communication
Keep in mind that communication is key. Any tools or process that help facilitate good communication should be part of managing your development group.So what do you call the development process that you are recommending?
Your manager may ask you what development process that you plan to address with your software configuration process. This really should be decided over meetings with the development manager. A software configuration process needs to cater to the development process, and a little software configuration management pre-planning can go a long way.The next section will make mention of a few things to consider based on the development process. Some development groups may not know what development process they will be using (scary I know but too often this may be the case!), so after reviewing the following processes you may be able to decide or even help guide the development manager in following the best fit process and picking the top notch tools to boot.
SCM models