Concepts: Promotion Method
Topics
Definition 
It takes a considerable amount of effort and investment on behalf of the project team to ‘mature’ a component for integration. The Promotion Method refers to how artifacts from an individual engineer’s development area (workspace) are made available for subsystem and system integration, build, testing, and release.
Explanation
Implicit in the Promotion Method is the protocol that needs to be followed as components are reviewed, re-worked, ‘promoted’ for sub-system and system level integration. The method also covers how components would be ‘sent-down’ for re-work and subsequent re-integration.
The Promotion Method also helps define project access control policies in terms of who in the project team can have access to, and change items in the product structure. The purpose of the access control policies is to prevent changes from being made without authorization, or at inappropriate times.
From the point of view of the developer, a typical set of steps that are followed when working on some files is to:
- Checkout the files you will working on,
- Edit these files,
- Unit test these changes,
- Get the changes approved, and
- Promote the changes for inclusion in integration.
Use
There are two methods for promoting components:
- ‘Check-In’’, and
- Private Branch.
‘Check-In’ Promotion Method
Under the ‘Check-In’ Promotion Method you begin by ‘checking-out’ some files that you want to update. When you are done with a change, you ‘check-in’ the files and they are automatically promoted and considered ready for integration.
Checking out a file creates a private copy of that file so that other developers will not see your changes until you ‘check-in’ the file.
A developer is notified that someone else is also working on the same file if he ‘checks-out’ an already ‘checked-out’ file.
The ‘Check-In’ Promotion Method works well for:
- Making small changes (< 1-3 days of effort),
- Making quick stabilization changes, and
- Coordinating small teams of developers (< 8)
However, the down sides to the ‘Check-In’ Promotion Method are that:
- ‘Checking-in’ files makes them visible to everyone. As such, there is an understandable reluctance to ‘check-in’ intermediate versions of partially completed changes.
- Long lived checkouts could result in divergences.
- Work in progress cannot be checked in, so it might not be backed up.
Private Branch Promotion Method
Under the Private Branch Promotion Method, you set up a private branch and are then free to check in and out any files you need in complete privacy from the rest of the team. Changes are merged back and made available to the rest of the team only after they've been completed and tested.
The Private Branch Promotion Method works well for:
- Working on changes that may destabilize the project (e.g. changes to the database schema)
- Working on changes that may not be included in the current release.
- Working on changes that could take a long time to implement.
However, the down sides to the Private Branch Promotion Method are that:
- Working on a different branch means that you will need to perform a merge to promote your changes. This may be non-trivial based on how long you have been working on a given branch.
- You will not be notified if someone else is also working on the same element in their own private branch.
