Я уже писал не раз, что на текущей моей работе мы использовали систему контроля исходного кода похожую на Visual SourceSafe (от Dynamsoft). Да-да это когда делаешь Check Out, а тебе стучатся в мессенджер и просят сделать поскорее Check In, так как кому-то тоже нужно бы с этим файлом поработать (кто не знает он лочит файлы на сервере, один файл можно менять только одному человеку за раз). Но это время наконец-то забыто, и мы планово перешли на Team Foundation Server 2010 около месяца назад. В сети есть куча примеров, как сделать импорт из Visual SourceSafe в TFS с сохранением всей истории, но, к сожалению, у нас был не совсем VSS, и тратить много времени на изучение, как это правильно сделать не хотелось, потому было решено просто залить последний рабочий код. Кстати, именно в это время у нас состоялся freeze версии, потому мы и нашли немного свободного времени, и спокойно начали переходить. Для системы bug tracking у нас использовался Redmine, достаточно удобная штука (да еще и бесплатная). Теперь для ведения задач у нас это TFS, а для форумов, wiki страниц и остального - это Windows SharePoint Services 3.0, который становится рядом с TFS. Что ж, хотелось бы поделиться немного своими впечатлениями.
Почему выбрали TFS? На этот вопрос мне сложно ответить, не я выбирал, а тот, кто выбрал, видимо, полагался на рекламу. Я бы посмотрел бы в сторону SVN/Mercurial и JIRA, как было на прошлой работе в ФогСофт (SVN+JIRA) – эти ребята в связке реально очень мощные. Точнее, каждый по отдельности выглядит мощнее, чем отдельные части TFS. Но вот TFS конечно выглядит лучше тем, как у него все интегрировано между собой – в этом, конечно, и есть его прелесть.
Система для ведения задач в TFS действительно классная, все задачи – это не просто набор полей, а с каждым типом задачи (Task, Issue, Bug, etc) связан еще Workflow, который говорит, как друг за другом должны идти статусы задачи (в принципе, такое реализовано много где). То есть, для примера, создается Task со статусом New на тебя, ты ее изучаешь и переводишь в Active с причиной Accepted (причем на выбор можешь либо начать задачу, либо закрыть, другого не дано), потом ты работаешь над кодом и при Check In изменений помечаешь задачу, над которой работал, ее статус меняется на Resolved автоматически c причиной «Complete and Requires Review/Test». Как удобно потом находить весь код, который был изменен в рамках определенной задачи. Соответственно, уже тестер сделает задаче Closed и поставит соответствующую причину (либо вернет в начальный статус, если там будет баг).
Еще один из интересных примеров – это, когда падает Build и тот кто был последний, кто сделал последний Check In сразу же получает задачу по починке билда, TFS автоматически создаст для него задачу. Но пока мы остались на CC.Net, потому этой прелести мы пока не видели.
Выбрали, кстати, мы стандартный шаблон MSF for CMMI Process Improvement v5.0, который поставляется по умолчанию. Хоть и говорят что очень много шаблонов, да еще и самому можно свой шаблон сделать. Попробовал я также устанавливать остальные (в смысле не те, что по умолчанию, а так еще есть хороший шаблон Agile от Microsoft) шаблоны: какие-то не работают нормально с Sharepoint, какие-то просто без нормальной документации, некоторые просто какие-то недоделки. Про сделать свой шаблон самому и речи быть не может, для этого нужно было за месяц до перехода сажать отдельного человека. Поэтому реально, выбора тут не особо то много.
В общем, шаблон был выбран, по картинке и на теории выглядит все классно, на практике попадаются мелкие проблемы. Вроде без труда все типы задач можно править, изменять, добавлять поля. Но вот сделать так, чтобы Priority был не “4,3,2,1”, а словами, вроде “Low, Normal, High, Urgent” – вот тут не так все просто. Менять нужно не просто в задаче, а еще и в специально подготовленных полях TFS, соответственно, нужно будет менять отчеты, не просто это и не быстро. Может, правда я еще не научился правильно готовить этот TFS, но как то страшно что-то сломать. И, кстати, если работаете с TFS, то обязательно ставьте Team Foundation Server Power Tools April 2010, этот плагин добавляет возможность править типы задач в нормальном редакторе, редактировать Alerts для всех (если у вас есть соответствующие права), ну и дает возможность посмотреть диаграммы, как я привел выше.
Другая проблема: непонятно что делать с пользователями типа NETWORK SERVICE, TFSSERVER/Administrator, я имею ввиду что их видно в списке Assigned To, а как их убрать? Удалить все привилегии, которые выданы этим аккаунтам, что-то я сомневаюсь, что все останется в стабильном состоянии. Правда, кстати, это отдельная песня, попробуй разобраться что куда, и какому пользователю какие права можно и нужно повесить. Вот почему не сделать как-нибудь по стандартному “Read, Write, Only My и т.п.”, ну как обычно все делают. Они наделали непонятных правил, по которым нужно, такое ощущение, иметь докторскую степень, чтобы все настроить. Сложно передать словами. У TFS есть еще очень приятный веб-интерфейс, при помощи которого так же запросто можно смотреть файлы в репозитории и работать с задачами (даже можно сравнивать файлы при помощи веб-интерфейса). Есть одна из 5 ролей – это что-то типа “Право на работу только с веб-порталом”, которому предоставляется только один список – “мои созданные задачи”. А вот как сделать, чтобы человеку можно было бы увидеть все задачи – непонятно. Не давать же ему права как разработчику, не хочется ему отображать лишние закладки, типа Source Code. Вот кстати, как выглядит web доступ к TFS, очень красиво (и что удивительно работает стабильно):
Дальше поговорим про Alerts, про оповещения. Без тех Power Tools, что я привел выше, вообще, непонятно как нормально можно настроить оповещения. Опять, забито около 5 типов оповещений, что-то вроде “Если правили задачу, которая назначена на меня”, “Если правили задачу любую задачу” и т.п. Благо Power Tools предоставили диалог Alerts Explorer, при помощи которого эти оповещения можно очень гибко настраивать. А так, до этого я подписался на все изменения задач (надо быть в курсе дела). Так наш team поигрался вечером с задачами, выстроил их в зависимости и т.п. и мне пришло под утро около 800 писем об изменениях в задачах, что их объединили. Теперь мы стали умнее и сделали оповещения только по жизненно важным полям, на которые нужно быстро реагировать, а это пока Title, Assigned To, Description, State, Comments. Так же еще кажется, что нужно бы ставить оповещения по Priority и Iteration, но на самом деле, если будет меняться Iteration, то статус задачи нужно будет менять с Accepted (выбранные задачи для текущей итерации) обратно на Proposed, а менять Priority задачи, над которой уже работают – неправильно (об этом, скорее всего, будут уведомлять лично), а если поменяли Priority до того как взялся за задачу, то ты это увидишь.
В Redmine у нас был еще удобный Wiki и форумы. Теперь на замену этому пришел WSS 3. Кто хорошо знаком с WSS, наверное, уже ухмыляется. Sharepoint, в плане wiki страничек и форумов – это работает, но это уж очень сильный минимум от того, чего хотелось бы. Проигрывает он Redmine сразу по нескольким показателям. То, что нормально он работает только в Internet Explorer еще, вроде, можно смириться, но вот всякие мелочи. Например, добавляешь сообщение на форум, хочешь добавить картинку: ты можешь добавить attachment, но он будет доступен только после сохранения этого сообщения, то есть ссылаться сейчас на него ты не можешь, и тебе либо два раза сохранять свое сообщение (второй раз редактировать), либо все класть в какой-нибудь отдельный WSS лист, и ссылаться уже на него. Удобно? Еще история: наш бизнес аналитик отдыхал на Z, пока мы совершали этот переход, когда вернулся у него соответственно была куча вопросов, как это все работает. Как только он открыл WSS – сразу же сказал “Вау, мне нравится”, я же мог только ответить “Подожди, скажешь через день как попробуешь с ним поработать.”, через час как я ему показывал все прелести этой системы он уже был сильно разочарован. В общем, только внешний вид у WSS выигрывает. Тут важно заметить, что WSS нам реально нужен только для форумов, wiki и хранения документов, никаких встреч, задач в WSS мы скорее всего организовывать не будем, хотя может наши менеджеры и научатся с ним работать. В задумках еще перейти на Sharepoint 2010 вместо WSS 3, только чувствую будет это не так просто, но в сети я видел примеры, как TFS 2010 и Sharepoint 2010 работают совместно.
Так как мы используем CCNet, то хотелось бы на Project Dashboard (главной страницы проекта в WSS) видеть информацию по билдам. Нашел я решение тут Show your CC.NET dashboard in Sharepoint. CCNet предоставляет xml данные о состоянии билдов по ссылке http://buildserver/ccnet/XmlServerReport.aspx, поэтому можно добавить на страницу Project Dashboard XML Webpart, указать в качестве данных ссылку и указать следующий XSLT (я его немного подправил, так как формат видимо изменился с того времени):
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" encoding="utf-8" indent="yes" omit-xml-declaration="yes" />
<xsl:template match="/">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<thead>
<th style="text-align:left;">Category</th>
<th> </th>
<th style="text-align:left;">Project</th>
<th> </th>
<th style="text-align:left;">Status</th>
<th> </th>
<th style="text-align:left;">Last buildtime</th>
<th> </th>
<th style="text-align:left;">Buildlabel</th>
<th> </th>
<th style="text-align:left;">Activity</th>
</thead>
<tbody>
<xsl:apply-templates select="/CruiseControl/Projects/Project"/>
</tbody>
</table>
</xsl:template>
<xsl:template match="Project">
<tr>
<td><xsl:value-of select="@category"/></td>
<td> </td>
<td class="ms-vb" align="top" nowrap="nowrap">
<xsl:element name="a">
<xsl:attribute name="onfocus">OnLink(this)</xsl:attribute>
<xsl:attribute name="href">
<xsl:value-of select="@webUrl"/>
</xsl:attribute>
<xsl:attribute name="onclick">GoToLink(this);return false;</xsl:attribute>
<xsl:value-of select="@name"/>
</xsl:element>
</td>
<td> </td>
<xsl:element name="td">
<xsl:attribute name="class">ms-vb</xsl:attribute>
<xsl:attribute name="align">top</xsl:attribute>
<xsl:attribute name="style">
padding-bottom: 3px;
<xsl:choose>
<xsl:when test="@lastBuildStatus='Failed'">
color:red;
</xsl:when>
<xsl:when test="@lastBuildStatus='Exception'">
color:red;
</xsl:when>
<xsl:when test="@lastBuildStatus='Unknown'">
color:yellow;
</xsl:when>
<xsl:when test="@lastBuildStatus='Failure'">
color:red;
</xsl:when>
<xsl:otherwise>
color:green;
</xsl:otherwise>
</xsl:choose>
</xsl:attribute>
<xsl:value-of select="@lastBuildStatus"/>
</xsl:element>
<td> </td>
<td class="ms-vb" style="padding-bottom: 3px;" align="top">
<xsl:value-of select="substring-before(@lastBuildTime,'T')"/> 
<xsl:value-of select="substring-before(substring-after(@lastBuildTime,'T'),'.')"/>
</td>
<td> </td>
<td class="ms-vb" style="padding-bottom: 3px;text-align:right;" align="top">
<xsl:value-of select="@lastBuildLabel"/>
</td>
<td> </td>
<xsl:element name="td">
<xsl:attribute name="class">ms-vb</xsl:attribute>
<xsl:attribute name="align">top</xsl:attribute>
<xsl:attribute name="style">
padding-bottom: 3px;
<xsl:choose>
<xsl:when test="@activity='Building'">
color:red;
</xsl:when>
<xsl:when test="@activity='CheckingModifications'">
color:yellow;
</xsl:when>
<xsl:otherwise></xsl:otherwise>
</xsl:choose>
</xsl:attribute>
<xsl:value-of select="@activity"/>
</xsl:element>
</tr>
</xsl:template>
</xsl:stylesheet>
А про Source Control от TFS я расскажу позже отдельно.