In 2004, I was appointed the configuration management leader in the company I still work for today. This was an exciting assignment for me, and in this article, I will share some of my experiences coming up to speed as a CM guru.
We were a relatively small company—about forty research and development members, with two products and long release cycles—and our CM was pretty basic: a popular source-control software, an old and rarely used bug-tracking tool, and some semicryptic shell-based build scripts. A team of two CM engineers was more than enough to handle everything.
A year went by. The company was doing well and recruited more employees slowly but steadily. At first, my team just needed to make sure we had enough software licenses to cater to new recruits, and luckily, management didn’t need the demand for a larger CM budget explained. I can’t stress this first lesson enough:
1. Managers need to be aware of the CM-related costs of recruiting more developers.
The first challenge we faced as a CM team was the bug-tracking tool. It was no longer supported, and we couldn’t purchase more licenses for it. Coupled with the fact that it was cumbersome to use and almost impossible to customize, there was no choice but to quickly look for a replacement. We went for the “natural” choice of using an advanced defect-tracking tool offered by our source-control tool vendor. It was a costly tool, and it required updated hardware, which increased the cost even further. But we had the budget, and this was a real game-changer for us. Suddenly it was easy to report and track bugs, run various reports, and customize both the data and the behavior.
Here we learned another lesson:
2. Tool customization must also be controlled.
Many users came to us with a lot of requests and suggestions—sometimes conflicting ones—and sometimes they had undesired side effects. For example, one team leader asked to make a certain field mandatory, which annoyed the other teams who didn’t need that field at all. We eventually established a “triage” that must authorize customization requests to the CM tools before my team implements them.
A couple of years later we were purchased by a large corporation, and then things started to get really interesting. We began developing new products, as well as adding large-scale features to the existing ones. More R&D staff was recruited, and at an increasing rate—in some cases, the number of employees grew by 10 percent in a single month.
As a small CM team, we had a lot to deal with as a result of this rapid growth. The three major issues we needed to constantly review (and revise as needed) were tool scalability, processes, and costs.
Scalability of most tools is pretty straightforward: Having more users means more data is generated, and more frequently. Hence, you need to make sure you can:
3. Support the repository growth, support multiple connections at once, and provide an adequate level of performance.
It comes down to getting better hardware and making sure the tool is up for the task.
In our case, the source-control and bug-tracking tools were designed for the enterprise, so we concentrated on upgrading the servers’ hardware. Instead of just gradually upgrading the hardware every time, we decided to do a one-time purchase of a couple of strong servers that were expected to last us for at least five years.