configuration management
Articles
|
Metrics and Process Maturity In keeping with the season, I'll try to keep this month's article on the Light side (both Chanukah and Christmas are Festivals of Light). Not easy to do when talking about metrics. If you're serious about attaining SEI CMM Level 5 certification, or about improving your processes in an effective manner, metrics are critical. Changing processes based on gut feel, or even based on some other organization's best practices can lead you backwards. Metrics not only permit you to detect this, but give you the basic data you need to improve your processes. |
||
|
Taking the Complexity out of Release Management CM is complex enough without having to worry about managing releases! Release management, however, isn't just part of CM, it should be driving your CM solution. Release management deals with defining, using and managing the set of deliverables (the Build), for all of your customers. This includes the creation of records to subsequently identify release contents, the creation of variant builds, patch releases, incremental releases, and the support of parallel streams of releases (older product releases, current release(s) and future releases). It also deals with the ability to know what’s in a release and to compare one release (e.g. one being sent to a customer) to another (e.g. the one the customer currently has so that the customer is well aware of the changes being made to his environment and how they match up against his requirements). In an end-to-end product management environment, release management spans the entire spectrum from requirements management through to product retirement. |
||
|
ABCs of BPD (Build, Package, and Deploy) Many in the software engineering world consider build, package, and deploy the core areas of configuration management (CM). To highlight this, many CM jobs are titled “build engineer” or “release engineer” with responsibilities that focus on the tasks of building, packaging, and deploying releases. |
||
|
Is It Upward Compatible? I want to touch on one of the most basic and fundamental issues of configuration management that developers have to deal with. A common question addressed early on in a project is: Do I need to branch this software and maintain a parallel version? A common answer is: Well, if it's not upward compatible. |
||
|
Making Incremental Integration Work for You Recent CM Crossroads posts have suggested that a branch-per-change branching strategy is good because it gives you the ability to maintain a stable "main" trunk, while integrating a change at a time if you want. As Joseph Reedick put it in one of his responses: |
||
|
Multi-Site Servers - Get it Right I've been involved in database development for 30 years and CM development for over a quarter century. I'm confused. Why is it so difficult to get working multi-site solutions? The specification is clear, to start off anyway: I want to see the same thing whether my client is connected to the London server or the New York server. |
||
|
The Importance of Software Builds: Building Earnestly Building your application is key to a successful, repeatable, development process. A reproducible build that works at all levels allows you to proceed with confidence and be more agile. Yet many organizations (agile and not) leave the build process to chance, even though all can benefit, regardless of their method. |
||
|
Aircraft Carrier Called the "CM" In the past, I had a window view of the Boston Harbor from my office. I could see boats coming in an out, including numerous tour boats, whale watch boats, and sail boats. Occasionally, I got the chance to see the large ships including the tankers, battleships, tall ships (e.g., elegant large sailing ships), and the rare site of an aircraft carrier. The aircraft carrier is a floating runway for jets. Imagine the infrastructure needed to get those incredibly fast jets ready and flying.
|
||
|
SCM Patterns: Building on Task-Level Commit “Dad,” asked a young man, “my lady friends keep talking to me about being ‘involved with’ them versus being ‘committed to’ them. What exactly is the difference between involvement and commitment?” “What did you have for breakfast, son?” his father replied. “Bacon and eggs like always. Why do you ask?” said the son. “Bacon and eggs, my boy, is a perfect illustration of the difference between involvement and commitment: the chicken was involved, but the pig was committed!” |
Austin Hastings
December 5, 2005 |
|
|
ABCs of Requirements Engineering Requirements engineering plays a fundamental role in the establishment of a release. Requirements engineering can be described as having five key areas of focus. This includes the ability to elicit requirements, document requirements, approve and baseline requirements, manage the requirements after approval, and trace from the requirements thru test.
|
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.