"Make Changes" is a generic activity to
accommodate the team members' need for access to the set of artifacts to
be changed (change set) in order to fulfill (through
performing various activities) the requirements of their work order.
Input
Artifacts:
Work Order
Resulting
Artifacts:
Project Repository
Work Order
Frequency:
On-Going
Role:
Any Role
Workflow Details:
Configuration & Change Management
Change and Deliver Configuration Items
The Work Order from project management is a stimulus to any work being
performed on a project. Uppon being given a work order, team members will typically plan
their work by creating "to do" lists with due dates that meet the
"contract" outlined in the work order.
The next step is for the responsible role to get or create the necessary artifacts that
need to be worked on or added to source control.
Projects usually maintain controlled versions of artifacts in a central,
restricted access, repository. Check-In and Check-Out are the operations that
enable development staff to obtain a particular version of an artifact, make
changes to it, and re-submit it to become the latest controlled version. The
purpose of this step is to ensure that developers follow 'check-in and
check-out' procedures to make changes to version controlled artifacts.
The primary CM operations performed by any member of the development staff
are:
Check Out
â Grants permission to change an element
Check
In â Stores a new version of the changed element and makes
changes available for Check-Out by other team members. A recommended
policy is that every check-in be accompanied by a brief comment describing
the change.
Add to Source Control â Places a new file or
directory under version control, creating the initial version
Deliver â Submits changes to the integrator.
Rebase â Makes changes made by other developers
available to your view.
An implementer will typically work in the following manner:
Checks out the files that need to be changed.
Makes the changes.
Performs unit tests to verify the changes.
Gets the changes approved.
Checks in the changes.
Promotes the changes.
Different Kinds of Check-Out
By default, checking out an element grants the exclusive right to create a new
version of it. This is called a reserved checkout. Another user who
attempts a reserved checkout of that element is prevented from doing so.
In parallel development situations, an unreserved checkout is a
mechanism to checkout a file even if someone else has already checked it out.
Some organizations routinely use a first-come/first-served style of development,
in which multiple users perform an unreserved Check Out of the same element. Any
one of them can subsequently perform a Check In, to create the next version of
that file. Each of the others must merge these changes with previously
checked in changes before creating a subsequent version.
Roles and Activities >
Any Role >
Make Changes