Continuous Integration для самых маленьких

По поводу миграций — рекомендую обратить внимание на штуку под названием FluentMigrator, позволяет писать миграции вида:

[MigrationDate (2013, 8, 17, 19, 50)]
public class MyMigration : Migration
{
	public override void Up ()
	{
		Create.Table ("GnsTags")
			.WithColumn ("EntryKind").AsEnum ("Merchandise", "Advertisement").NotNullable ()
			.WithColumn ("EntityId").AsUInt32 ().NotNullable ()
			.WithColumn ("Tag").AsString ().NotNullable ();
		Create.Column ("IsDeleted").OnTable ("GnsGoods").AsBoolean ().NotNullable ();
	}
	public override void Down ()
	{
		//Тут код отката в том же стиле
	}
}

Поддерживает несколько движков БД. Из минусов могу назвать только тот факт, что миграции всё же приходится писать вручную.

Вообще, все предлагаемые структуры VCS преследуют одну цель: избежать ситуации, когда ветка разработки не стабильно, а совершенно необходимо что-то быстро «пофиксить» или «допилить» и выложиться.

Лично мне нравится, когда в VCS одна общая ветка, а бранчи создаются из истории при необходимости (а не сразу после релиза). Так значительно проще.

Мне вот интересно, почему в каждой статье про CI забывают упомянуть про то, что бывают gated checkins, когда код, который не проходит тесты, просто не попадает в репозиторий? Это (очень) резко уменьшает количество сломанных билдов в CI и вообще битого кода в репозитории.

В одной компании, где я работал проблема со слишком часто сломанным билдом была решена правилом: сломал билд – принеси тортик. Сначала торты ели каждый день, потом перестали.

Как-то так…

Я предпочитаю большинство действий делать при помощи MSBuild'a, а TeamCity только запускает нужный таргет.
Таким образом, я могу из командной строки сделать любое действие над проектом — прогнать тесты, сделать бекап базы, обновить базу, обновить сайт в ИИСе,…

Статья очень, очень хорошая, но не могу не вставить свои пять копеек.

— Про версии сборок. Хочу обратить внимание, что у Microsoft термины Revision и Build поменяны местами. То есть семантически всё верно: закоммитил исходники — изменилась третья цифра, сбилдил на CI — изменилась четвёртая цифра. В документации с точки зрения смысла всё правильно, но названия параметров поменяны местами. Начинающему CI-мастеру легко запутаться.

— Про миграции базы данных. Если используется SQL Server (что для .NET частое явление), то можно использовать SMO. Через SMO можно управлять всем функционалом SQL Server, а не только alter на таблички делать. В статье упомянуть об SMO стоило.

— Про публикацию служб. Для доставки бинарников на сервер подходит тот же MSDeploy. Если в проекте уже используется MSDeploy для публикации web-приложений, то одной командой sync в MSDeploy можно скопировать все бинарники сервиса на целевой сервер. Шаред-папка и FTP это уже не модно :).

— Параметры в TeamCity. Учите людей плохому. Кучу аргуметов через /P указывать в TeamCity не надо — работать будет, но будут warnings. Специально для этого есть Build Parameters, они прозрачно транслируются в MSBuild скрипт.

Ну а в целом, если поговорить по душам, меня немного напрягает декларативный синтаксис MSBuild. Если стоит задача после билда сделать пару нетривиальных приседаний, то надо искать сторонные библиотеки с тасками для MSBuild, либо писать эти таски самому.

Я больше склоняюсь к использованию PowerShell и конкретно psake. Это императивные скрипты, а не декларативный XML как в MSBuild, их не надо компилировать, можно легко править и можно отдать поддержку этих скриптов админам (от них сейчас знание PowerShell стали требовать).

Что думаете по этому поводу?

Версионирование продукта
На мой взгляд удобнее всего использовать msbuild и проставлять значение с помощью CI-сервера:

Как решается обратная задача? Пользователь репортит о проблеме, указывает версию продукта (скажем, посмотрев свойства dll'ки в Проводнике): 3.14.159.2. Как узнать, какой ревизии в репозитории соответствует эта версия сборки? Используется DVCS, где для идентификации ревизий применяется 1) немонотонный 20-байтный уникальный идентификатор, и 2) автоинкрементный, но неоднозначный номер (может различаться для одной и той же ревизии в разных клонах репозитория).

Не могу не упомянуть опенсорсный CI-сервер CruiseControl.NET. У нас он работает в связке с Redmine.

Для автоматического изменения версий сборок есть еще подход, описанный здесь (основан на использовании build feature «AssemblyInfo patcher»).
Из преимуществ — сам изменяет номера сборок во всех AssemblyInfo.cs в солюшене, не надо править .csproj как описано в этой статье. Из недостатков — изменяет номера сборок для всех проектов в солюшене, т.е. не позволяет для разных проектов вести различное версионирование.