Green, the planet, ecology; whatever the phrase, the environment is on people's minds. The environment and configuration management share a lot of the same ideals, concepts, and rules. Thinking about configuration management planning from the perspective of an environmentalist helps a CM team plan for for future events in a fairly low future-cost way.
Reduce, Reuse Recycle
As CM professionals, we desperately want to reduce breakages, lines of code, and infrastructure wherever possible. Much like application development, reducing lines of code, and existing infrastructure makes for less to maintain, less to manage, and most importantly, less to replace in the future. We always strive to reduce complexity in a our processes, our tools, our workflow, and our code. As a general rule, the less to maintain, the less that might break.
Reuse is another great example of reduction. How can we reuse existing infrastructure for current needs. What about existing code, and technologies. While writing something from scratch can be a tempting solution, the cost of maintenance tends to be higher than that of supporting an existing tool. For example, extending an existing revision control set-up can be much cheaper that migrating to a new system.
On the other hand, we'll find creative ways to reuse technologies. In the case of existing code, maybe we can subclass, or extend. Maybe we can write the “glue” between technologies and libraries. Virtual machines and chroot jails are possibilities that might help you reuse hardware, or better provision existing hardware. Or maybe an existing build system, or revision control server can be “bent” to meet current needs, without sacrificing anything important.
Recycling existing hardware makes sense environmentally, and from an SCM perspective. Examine how can you can move machine workloads around to free up hardware. Look at system utilization to better plan for resourcing, and re-provision existing hardware and systems wherever possible. More importantly, be prepared to recycle ideas. Just because something doesn't fit, or is too old for a specific point in time or situation, doesn't mean that it's not generally viable.
Think Globally, Act Locally
My favourite lesson from the environmental movement has always been “think globally, act locally”. How can a problem be addressed in a reasonably generic way (or global), while still solving the specific product's (local) issues. With a build system, this is fairly easy to do. Whether you're using Make, (N)/Ant, or SCons, there's always a way to address problems in a product-agnostic fashion.
Some languages require that you make global rules and override them. Others support creating a collection of shared functions, actions, or targets. In target based build languages such as Ant and NAnt, it's relatively easy to have a shared target in a global build system, and then have it call the “local” target if it exists, as in the example below:
When planning for configuration management, remember the “think globally, act locally” pattern. For a little bit of upfront effort, it's possible to yield significant savings, while at the same not overindulging in the tendency to write overly-generic modules.
Everything is Interconnected
While true of any system, this axiom above is a mantra every configuration management professional should learn to live by. A good CM and build system has as few dependencies as possible on the outside world. Ideally the dependencies would be limited to networking and power, not external servers or services over which the CM team has little control. The same should apply internally.
We need to accept that our system is interconnected between file shares, web and database servers, revision control systems, network availability, or some other dependency we haven't thought of. But, while everything is interconnected, we need to reduce the level of interconnectedness, in order to reduce possible failure points, our footprint, and to make things easier to manage.
Look at using protocols that are more tolerant to faults. Analyse transfer times between systems to understand bottlenecks, packet patterns, and simply, where the time goes. Verify that operating system choices are good ones, and that those operating systems are tuned properly. This sort of proactive information gathering can yield terrific dividends. One build system I audited, managed to decrease their transfer times by 35%, solely by changing a routing table. In another case, we reduced checkout times by nearly 50% solely by reducing changing, and then tuning the operating system on the revision control server.
Keeping track of the interconnectedness of things makes terrific sense for configuration management planning. Tracking and understanding the flow of information through the CM system can help us reduce our failure points, and failure rates. Understanding, and then reducing these dependencies, helps make for a stronger CM system, and a more fault-tolerant one.
Everything Goes Somewhere
There's no Such Thing as a Free Lunch
Whether we're talking about the planet, or the configuration management, lunch is never free. Every branch, every build, every path adds a minute strain to the system. The key is to understand the effect choices have over time, to enable the CM team to account for this in their planning.
Keeping track of resource consumption across the network, whether in the form of disk space, processor utilization, or network utilization helps account for the cost associated with “free” events. Using a tool to track these details on developer desktops makes it even easier to qualify the cost associated with branching, and make the business case for a hardware investment. Whether the effect is on storage, network, or even time, the point is that nothing is free. Each branch has a ramification, and that's before we look at handling merge issues.
Just like with the planet, we want to reduce the footprint of our configuration management system, and activities as much as possible. We'll never be able to hit a zero footprint, or “free lunch”, but that doesn't mean we shouldn't try to trend as close to zero as possible. From the configuration management point of view, we can trend towards that free lunch with automation and monitoring. By donning our system's administrators caps, we can monitor over time, and plan for automation, with the goal of getting as close as possible to our very lunch.
Nature Bats Last
While we've discussed the environmental affect of our systems, we've almost completely ignored our users. If we were to approach the environment as a baseball game, we'd realize that nature bats last. In the case of SCM, we need to realize that our users, represent nature, and that they have the last at-bat. No matter how much effort we put into planning for CM, nature, or our users will invariably require am unplanned response. People will always have their own opinions, wants, and even need; these are the things that lay a plan to waste, if the plan doesn't include flexibility.
People will always have needs outside of the design of the CM system. Planning for the unexpected can yield terrific results, but it invariably leads to the question “how do I plan for the unexpected?”. Part of that leis in our earlier discussion, understanding what you have and what you can support, or in this article's parlance, understanding that everything is interconnected.
Knowing your available disk space, processing power, and network availability, helps deal with human nature. Flexibility in design, whether it's using something as simple at getopt compliant options in scripts, or overrideable variables in a build system, help you accept these future goals, and roll them into the plan. Never imagine that all your users want to work in the same manner, use the same, tools, or interact with the system in the same way.
Reacting to Today, Planning for Tomorrow
Much like the planet, a build system has to deal with today's reality, prior to planning for the future tomorrow brings. Think about triage; try to understand what you can do today, to plan for a better tomorrow. How can the team plan for the future CM needs of the organization, while meeting today's goals? That challenge can best be met by asking the questions above, and preparing for the future in the least intrusive manner possible.
Sure, today's situation is not ideal; but much like with the environment, our goal is to strive for the idealized future. Plan for tomorrow, and work on implementing today.
Chayim Kirshen is the Build Manager at PlateSpin ULC, a Division of Novell. As an experienced professional with over a decade of experience, his prior engagements have included the Telecommunications, Financial, Healthcare, and Education sectors. Chayim manages a combined build and release engineering team, planning and developing with a SCRUM development process. He loves GNU Make, NAnt, and breathes python and revision control systems. Chayim can be contacted through his website, http://www.gnupower.net , or at [email protected] .
