Earlier, I referred to the term 'Checkin Experience' - I would like to expand on that a bit to make sure everyone is aware of what it is.

The 'Checkin Experience' consists of:

  • Selecting which files to include in a checkin (changeset)
  • Selecting which work items (bugs, tasks, ...) to associate with a checkin
  • Selecting which work items to resolve/close with a checkin
  • Filling in required and optional checkin notes
  • Ensure the checkin policies are met

Selecting which files to include:  This allows you to select all or a subset of files to include in a checkin (changeset).

Selecting which work items to associate with a checkin:  This allows you to associate a work item with a checkin; once associated, you can view changeset details to see which work items were associated with a particular checkin.

Select which work items to resolve/close:  This allows you to select which work items should be moved to the “next“ state.  For example, if a work item is in an active state, selecting it would move it to a resolved state; similarly, if a work item is in a resolved state, choosing it would close it.  [Note that the example transitions are samples only - work items are configurable, so they transition based on current state and the checkin action against it].

Filling in required and optional checkin notes:  By now, hopefully everyone has the concept of a portfolio project; for each portfolio project, checkin notes can be configured.  These checkin notes can be either optional or required for a checkin.  Some sample of checkin notes would be: “Build instructions“, “Code reviewer“, “Documentation Changes“, ...  One of the many uses of release notes is to query all release notes prior to shipping a product (more specifically new releases/patches); the readme.txt or other documentation can then be created from these notes.

Ensure Checkin Policies are met:  These are great!  There is an API to write policies against.  All the policies that have been created will then be run prior to a checkin.  This allows groups to ensure standards across a development team.  There are many possibilities for policies including:

  1. Ensure no tabs are in source code.
  2. Make sure a copyright notice is at the top of each source file.
  3. Make sure coding guidelines are followed.
  4. Ensure code coverage percentages are met on unit tests prior to check.

Next posting I will go into policies much more...