Agile Codeline Management

on one codeline (the mainline), and managed library code from other vendors on a separate codeline (third party codeline).

When you create your workspace for development you would have a script that checks out the appropriate versions of the appropriate components from each codeline into your workspace. Each codeline has a codeline policy associated with it. The codeline policy describes how the codeline is to be used. Examples of items that may be included in codeline policies are listed below.

• How often to check in changes
• How much testing and validation is required before a check-in
• Who can check-in changes and when

During development on the mainline, you may encourage people to check things in frequently, but you want to control changes to the third party codeline more closely. There are many approaches to managing codelines and deciding how few, or how many codelines to have for a project. The most effective approach for agile environments is to do all of your work on a single codeline, a mainline. The mainline can be supplemented by components from a third party codeline.

Mainline development by itself is not enough for agile development though. Agile development requires frequent integration. If you have a policy of maintaining a mainline of shippable quality at all times, you may find that the cost of checking-in code is high enough that developers will check-in only once or twice a day. For example, if you verify quality by an exhaustive set of tests that take an hour to run, there is an incentive to code as much as possible before starting the test, say before going out to lunch. (This also means the there were a lot of changes in each check-in, making it harder to determine what broke.)

If you take the further step of making sure that only one person is checking code in at a time using a semaphore mechanism, you could be locking out the entire team. An Active Development Line approach has advantages if you don't need to be 100% sure that the codeline is perfect on a minute to minute basis. With the appropriate use of simple tests like unit tests and smoke tests, developers can check code in quickly. Exhaustive tests such as regression tests, can run on an integration machine periodically.

Branches
Single Active Development Line has many advantages in terms of simplicity, consistency, and minimizing duplication. There would be many advantages to always delivering a product off of the current active codeline. There are some situations where you discover that there are benefits to having a version of the code evolve independently for a strictly limited time. This is where creating a branch is useful, especially in an agile environment (or an environment trying to be more agile).

A common branching pattern is a Release Line. Consider a scenario where you deliver an application to the customer, and then start work on the next version. In spite of what you imagined to be thorough testing, your customer finds a critical problem in the code. In this situation you have three choices. You can ignore the problem until the next release is done, get the current codeline in shape to ship the customer a new version, or provide the customer with a fix based on the version that they have. Each solution has merits and disadvantages, but you should make your decision based on the needs of the situation rather than fear.

Ignore It
If you have a frequent enough release cycle it may be feasible to ask the customer to wait until the next release. Whether this is