|
Source Control Checkins This month, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file. Editing a Single File Consider the simple situation where a developer needs to make a change |
||
|
Self-Documenting Makefiles < |
||
|
Why SCM Should be an Independent Entity Why a Configuration Management (CM) department should be independent from Development, Test, and Production. When deciding where to organize an SCM team within a development organization it is helpful to keep in mind that the three most important characteristics of the SCM role are objectivity, skill set, and focus. This document will show that an independent SCM department is the only group with the right mix of these characteristics to successfully implement and support a full range of SCM services. |
||
|
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. |
||
|
Source Control HOWTO: Repositories Cars and Clocks |
||
|
Learning from Concurrent, Parallel, and Distributed Systems Design This month we do a bit of a context switch from the world of parallel development to the world of concurrent, parallel, and distributed systems design (and then back again). The purpose is to see if any of the same patterns of concurrent, parallel, and distributed processing apply to the case of concurrent, parallel, and distributed development. |
||
|
Configuration Management VS Change Management - Who's in Control Discussion has gone around a number of times on the issue. There's even been a poll on the issue. Is configuration management part of change management or vice versa? Everyone has an opinion and there does not seem to be a consensus. What's the problem? Well, here's how I see it. |
||
|
History: Confronting your Past You may now be tired of hearing me say it, but I will say it again: Your repository contains every version of everything which has ever been checked in to the repository. This is a Good Thing. We sleep better at night because we know that our efforts are always additive, never subtractive. Nothing is ever lost. As the team regularly checks in more stuff, the complete historical record is preserved, just in case we ever need it. But this feature is also a Bad Thing. It turns out that keeping absolutely everything isn't all that useful if you can't find anything later. |
||
|
Evaluating CM Tools How do you evaluate a CM tool? What's important to you? Did you know that a good CM tool could actually make the difference between success and failure? |
||
|
Approaching Parallel Development with Branch - Merge Strategies Many times when managers first consider parallel development, it appears to be a very effective way to manage changes to concurrent streams of development. This is somewhat true if the project uses an SCM technology that allows for stable branching and establishes discreet project and maintenance branches. However, what is often forgotten is that while branching is a great way to separate code changes, at some point merging will have to occur. This article provides guidance for approaching and performing parallel development. |
Pages
Upcoming Events
| Apr 27 |
STAREAST Software Testing Conference in Orlando & Online |
| Jun 08 |
AI Con USA An Intelligence-Driven Future |
| Sep 21 |
STARWEST Software Testing Conference in Anaheim & Online |
