The Work Order from project management is a stimulus to any work being performed on a project. On 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 work products that need to be worked on or
added to source control.
Projects usually maintain controlled versions of work products in a central, restricted access, repository. Check-In
and Check-Out are the operations that enable development staff to obtain a particular version of a work product, 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 work products.
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.
-
Promote 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.
|