Generating Custom TFS Check-in E-mails – Part 3.5

I realized that I haven’t talked anything about how the whole TFS Spam system hangs together, something that may be useful as I go on with this series. In my best managerial style I, of course, broke out PowerPoint to create a pretty picture that shows the major components of the system (click the image to see a larger version):

I apologize for the use of PowerPoint and promise that I’ll try not to use it too often.

Everything starts with a check-in to TFS (as I’ve mentioned, we’re still on TFS 2005 but will upgrade to TFS 2008 in the not too distant future). Any time something is checked-in, the TFS server raises an event to any interested parties. You can read more about the event system in TFS here.

In our case, we have a web service that sits and listens for these events and when one is received, it parses the notification to get the id of the changeset from the notification data. The notification comes in the form of a relatively simple XML document:

<?xml version=”1.0″ encoding=”utf-16″?>
<CheckinEvent xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <AllChangesIncluded>true</AllChangesIncluded>
  <Subscriber>user name</Subscriber>
  <CheckinNotes>
    <CheckinNote xsi:type=”NameValuePair”
                 name=”Code Reviewer” val=”" />
    <CheckinNote xsi:type=”NameValuePair”
                 name=”Performance Reviewer” val=”" />
    <CheckinNote xsi:type=”NameValuePair”
                 name=”Security Reviewer” val=”" />
  </CheckinNotes>
  <PolicyFailures>
    <PolicyFailure xsi:type=”NameValuePair”
                   name=”[Invalid Policy]”
                   val=”Internal error in Changeset Comments Policy” />
  </PolicyFailures>
  <CheckinInformation />
  <Artifacts>
    <Artifact xsi:type=”ClientArtifact”
              ArtifactType=”Changeset” ServerItem=”">
      <Url>changeset link to standard TFS web UI</Url>
    </Artifact>
    <Artifact xsi:type=”ClientArtifact”
              ArtifactType=”VersionedItem”
              Item=”item name”
              Folder=”item folder path”
              TeamProject=”project name”
              ItemRevision=”revision number”
              ChangeType=”edit”
              ServerItem=”item server path”>
      <Url>item URL</Url>
    </Artifact>
    <Artifact xsi:type=”ClientArtifact”
              ArtifactType=”VersionedItem”
              Item=”item name”
              Folder=”item folder”
              TeamProject=”project name”
              ItemRevision=”revision number”
              ChangeType=”edit”
              ServerItem=”item server path”>
      <Url>item URL</Url>
    </Artifact>
  </Artifacts>
  <Title>
    event title (the same one you’d see in the standard e-mail
    subject header).
  </Title>
  <ContentTitle>
    Changeset 43690: Changed the action and namespace
    information for the Notify method. Also changed…
  </ContentTitle>
  <Owner>user name</Owner>
  <Committer>user name</Committer>
  <Number>43690</Number>
  <CreationDate>2/12/2008 11:06:08 AM</CreationDate>
  <Comment>check-in comment</Comment>
  <TimeZone>Pacific Standard Time</TimeZone>
  <TimeZoneOffset>-08:00:00</TimeZoneOffset>
  <TeamProject>project name</TeamProject>
  <PolicyOverrideComment>Policy issue.</PolicyOverrideComment>
</CheckinEvent>

You’ll recognize much of the information in this notification document from the standard check-in e-mail that TFS can produce.

Once we have the id of the changeset, we pass that to a class that processes the changeset. At a high level, this class generates a XML document that contains the information about the changeset, including all the code file differences and then processes this document with a XSLT transform which generates a HTML document that gets e-mailed to the configured subscribers.

All-in-all, there’s nothing particularly fancy about this, but it’s still useful to know how things hang together.