The Latest
An Interactive GNU Make Debugger[article] The interactive GNU debugger has breakpoints, dumps information about the rule at which a breakpoint is hit and allows interactive querying of variable values and definitions. |
||
Multi-Site Servers - Get it Right[article] 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. |
||
Agile Build Promotion: Navigating the Ocean of Promotion Notions[article] In this article Brad Appleton delves into the realm of build status accounting to discuss various build promotion models and how to choose an appropriate and effective implementation of a build promotion lifecycle. |
||
Merge Branches[article] What is "Merge Branches?" Many people find the word "merge" to be confusing, since it seems to imply that we start out with two things and end up with only one. I'm not going to start trying to invent new vocabulary. Instead, let's just try to be clear about what we mean we speak about merging branches. |
||
Release Management[article] The first thing that comes to mind about release management is how frequently releases are made and their levels, i.e. full release or patches. A common understanding of Release Management is that it is the management of introducing controlled items into a production (live) environment. But in reality release management is much more than this. “Release management is the process of planning, building, testing and deploying hardware and software, the version control and storage of software.” (British Educational Communications and Technology Agency, release management, Retrieved from http://www.becta.org.uk/tsas/index.cfm?refsect=ntss&bcsect=default§=release&id=tt5281 ) release management is not just what goes into production but also how something goes into production. It is the complete management of your production environment. |
||
Making Incremental Integration Work for You[article] 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: |
||
Building For Success[article] This article addresses detailed scenarios and the associated problems with the build process. We look at the usually activities and work patterns of a developer and relate those to build practices. |
||
Integrated Tools Enhance Distributed Development[article] When I look at the prospect of a distributed development effort, it scares me. So much depends on having the right people and good communicators, all in the right places. It also depends on the successful merging of cultures, but more and more distributed development is taking place. |
||
Using Merge To Yank A Change[article] I'll keep this one short. If you have a change that has been made to a file (or even to a change package of files) somewhere in the past and you would like to eliminate that change from the past, you can do so with a judicious use of almost any merge tool. |
||
ABCs of BPD (Build, Package, and Deploy)[article] 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. |
||
Source Control HOWTO: Repositories[article] Cars and Clocks |
||
Going Over the Fence[article] Software, we know, can be outsourced like sneakers, rubber balls, and helpdesks. That will put a damper on us in the career field of software configuration management. In the immortal words of the governor in Blazing Saddles, “We need to save our phony baloney jobs!” But what if we weren’t just managing software? What if we could apply the same principles to other products? Could we evolve into something more? Something bigger? Dare I say profitable? |
||
Taking the Complexity out of Release Management[article] 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. |
||
How to Implement Continuous Integration[article] The term “continuous integration” is getting a bit of attention these days. It refers to the process of integrating often (or immediately) to reduce integration effort, complexity, and pain.It allows for others make changes more readily. While the term “continuous” is catchy, it is not accurate in what the concept implies. In context to integration, it implies a process without interruption. |
||
Don't Become Hostage to Development Process Suites[article] Not many years ago, there seemed to be an increased demand that software development tools become better integrated. Now, it is expected that all software process tools from a single software house are tightly integrated. I started evaluating software process suites, and started promoting them to our development teams. |
David Baird
December 5, 2005 |