Комментарии 46
По поводу миграций — рекомендую обратить внимание на штуку под названием 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 ()
{
//Тут код отката в том же стиле
}
}
Поддерживает несколько движков БД. Из минусов могу назвать только тот факт, что миграции всё же приходится писать вручную.+1
Вообще, все предлагаемые структуры VCS преследуют одну цель: избежать ситуации, когда ветка разработки не стабильно, а совершенно необходимо что-то быстро «пофиксить» или «допилить» и выложиться.
Лично мне нравится, когда в VCS одна общая ветка, а бранчи создаются из истории при необходимости (а не сразу после релиза). Так значительно проще.
0
Мне вот интересно, почему в каждой статье про CI забывают упомянуть про то, что бывают gated checkins, когда код, который не проходит тесты, просто не попадает в репозиторий? Это (очень) резко уменьшает количество сломанных билдов в CI и вообще битого кода в репозитории.
+8
Вы когда-нибудь видели GC в крупных проектах, а не коде с одной сборкой? :) Гораздо более распространенная практика — не давать деплоить куда-либо при непрохождении некоего code-quality билда.
+1
Вот по этому и не упомянул.
0
я видел, на текущем проекте именно так и работаем.
это адъ.
это адъ.
+3
Я не просто видел, я так работаю. И в чем проблема?
Как раз наоборот, на коде, где больше одной сборки, это становится критичным, потому что зависимостей больше, и учесть их все становится сложно.
Как раз наоборот, на коде, где больше одной сборки, это становится критичным, потому что зависимостей больше, и учесть их все становится сложно.
+1
Вижу у себя на работе. Что не так с крупными проектами?
0
Ну, с точки зрения разработчика все шикарно: пушнул и пол-часа куришь. Время адекватного реагирования на изменения в коде возрастает в разы. И смысла немного. С точки зрения безопасного кода на проде (тесте и и.п. ) гораздо лучше тот вариант, что я описал.
+1
А что мешает мощности-то нарастить? Слава б-гу, билд-сервера дешевле разработчиков.
Ну и да, правило большого пальца: пречекин должен выполняться за пять минут. Если это не так — вы либо правите тесты, либо сокращаете тесты, либо наращиваете мощности. Либо комбинируете подходы.
Ну и да, правило большого пальца: пречекин должен выполняться за пять минут. Если это не так — вы либо правите тесты, либо сокращаете тесты, либо наращиваете мощности. Либо комбинируете подходы.
0
Наше бух-приложение хреново работает на 32-процессорном сервере, что мы лохи, что ли, давайте затарим прайват клауд, да, слыхал такое. К успеху идете :)
+2
Специально для таких комментариев был первый пункт: «правите тесты».
0
Обычно, при начальной оценке проекта, некоторая доля времени выделяется на не-функциональные риски и нужды(ну там, заболеет кто, инфраструктуру надо настроить, в конце-концов, никто в команде не работает 8 из 8 часов в день и т.п.), но вот правда, ни разу не слышал, чтобы кто-то закладывал время на правку юнит-тестов, потому что они сильно медленные или тяжелые. Какой в этом смысл? Зачем за это платить заказчику? Юнит тесты могут хоть 2 часа работать, главное, чтобы выполняли свою роль, а для долгих тестов всегда есть nightly builds.
0
Знаете, я тоже не слышал, чтобы при начальной оценке проекта закладывали время на правку производительности кода…
Ну и да, если вы считаете, что юнит-тесты могут хоть два часа работать — значит, вы не понимаете роли юнит-тестов. Никто не будет гонять тест-сьют, который идет два часа, а значит, весь смысл потерян.
Ну и да, если вы считаете, что юнит-тесты могут хоть два часа работать — значит, вы не понимаете роли юнит-тестов. Никто не будет гонять тест-сьют, который идет два часа, а значит, весь смысл потерян.
0
Да, я дейтсвительно считаю, что если в проекте есть UT, их много и они в сумме работают 2 часа — то это ОК. Опять же, напомню, мы говорим о больших проектах. Обычный девелопер, работая с модулем ранит небольшой сьют, которые отрабатывает за 2-5 минут, после чего он спокойно может коммитать свои изменения. Ну ОК, про 2 часа я может переборщил, но доводилось видеть .Net проекты, на которых билд с юнит-интегрейшн-тестами длился 1.5 часа. Для других платформ просто билд может идти весьма долго ;)
0
Вот не надо путать юнит-тесты и интеграционные тесты? Если у вас все юнит-тесты на проекте идут два часа — выделяйте BVT и гоняйте только их.
(а вообще это все прекрасно описано что у Мезароса, что у Хамбла/Фарли)
(а вообще это все прекрасно описано что у Мезароса, что у Хамбла/Фарли)
0
Да что же Вы все передергиваете? :) Где я по-вашему спутал U|I tests? Верификейшн тесты естественно выделяются и естественно именно они ранятся на code-quality builds. Но, я пытаюсь Вам сказать, что не всегда даже билд укладывается в 5 минут (просто билд без всяких bvt). Если, конечно, у Вас некомпилируемый язык, то тут гораздо все проще.
0
Не укладывается именно билд — ищите железо, ищите способы оптимизации.
(знаете, наверное, поговорку про «кто хочет»?)
Тут, как бы, очередные весы — либо вы тратите силы на то, чтобы сделать работающий пречекин, либо вы тратите силы на поиск багов на этап позже, чем могли бы. Выбор ваш.
Главное — не говорить, что если у вас пречекины не работают, то они нигде не заработают.
(знаете, наверное, поговорку про «кто хочет»?)
Тут, как бы, очередные весы — либо вы тратите силы на то, чтобы сделать работающий пречекин, либо вы тратите силы на поиск багов на этап позже, чем могли бы. Выбор ваш.
Главное — не говорить, что если у вас пречекины не работают, то они нигде не заработают.
+1
Заработают, да, на небольшом коде, либо на python'e/php. А по-поводу железа, мне было бы интересно посмотреть за просьбами выделить новый сервер под билд-машину, вернее, посмотреть на лицо ПМа/заказчика в этот момент.
ОК, ладно, не буду спорить, я Вашу точку зрения понял.
ОК, ладно, не буду спорить, я Вашу точку зрения понял.
0
Заказчику до этого вообще дела нет, РП — тоже. Это обычно проблемы собственного инфраструктурного отдела компании, приблизительно того же, где «нам не хватает места на сервере БД» и «дайте сервер под VCS».
Когда нам понадобилось, мы сравнительного легко нашли не один, а четыре билд-агента.
Когда нам понадобилось, мы сравнительного легко нашли не один, а четыре билд-агента.
0
А можете поделиться, на каком стеке вы работаете, сколько проектов в солюшне, сколько тестов, сколько агентов, сколько разработчиков, одна ветка разработки или бренч на фичу/команду?
+1
.net, 35 проектов, 34 тестовых проекта, порядка тысячи тестов, гоняется две трети. Разработка на мейнлайне. Четыре или пять билд-агентов с разными задачами.
Остальное, извините, NDA.
Остальное, извините, NDA.
0
Что-ж, здорово, что есть позитивный пример такого сетапа. Мне больше нравится подход, когда команда комитит в свой бренч, дальше тимлид/другое ответственное за ревью лицо ревьюирует код только потом идет мерж.
Со временем стал приходить к мысли, что никакие технические ограничения не смогут сделать команду лучше. Если разработчики заливают битый код и уходят домой, то это должно решаться не техническими средствами, а увольнением таких «специалистов».
Со временем стал приходить к мысли, что никакие технические ограничения не смогут сделать команду лучше. Если разработчики заливают битый код и уходят домой, то это должно решаться не техническими средствами, а увольнением таких «специалистов».
+1
Что-то вы все в кучу валите. С двух часов только юнит-тестов (это их тысяч сто должно быть) перескакиваете на полуторачасовой полный билд. Вы уж определитесь ;).
Наш ночной билд исполняется 5 часов (он действительно дофига большой и страшный). При этом GC билд исполняется 7-8 минут (из них юнит-тесты — это пара минут). Зачекинил и работаешь дальше.
Наш ночной билд исполняется 5 часов (он действительно дофига большой и страшный). При этом GC билд исполняется 7-8 минут (из них юнит-тесты — это пара минут). Зачекинил и работаешь дальше.
0
Юнит тесты могут хоть 2 часа работать
Ключевое слово выделил.
ОК, какой смысл вашего GC в таком случае? Просто проверить, что код собирается?
0
1) Если компиляция продукта и прогон юнит-тестов (быстрых!) у вас занимает полчаса, то вы что-то делаете не так.
2) Курить не нужно. Просто продолжаешь работать дальше.
2) Курить не нужно. Просто продолжаешь работать дальше.
0
Бывает, тесты падают случайно, для selenium тестов через интерфейс это вообще не редкость. Так что на GC будет тратится слишком много времени разработчиков.
0
Во-первых, если тест падает случайно, это плохой тест (потому что ложные срабатывания — это время того, кто с тестом работает, не важно, разработчик это или программист).
А во-вторых, интерфейсные тесты в пречекин (обычно) не ставятся, потому что медленные.
А во-вторых, интерфейсные тесты в пречекин (обычно) не ставятся, потому что медленные.
+2
Во первых, про плохой тест объясните отвалившемуся браузеру, или БД, или неожиданно долгому коннекту, прерванному по таймауту.
А во-вторых, если тестов мало — разработчик может прогнать локально, а если много, то «потому что медленные», не вижу тогда большого смысла.
А во-вторых, если тестов мало — разработчик может прогнать локально, а если много, то «потому что медленные», не вижу тогда большого смысла.
0
Во первых, про плохой тест объясните отвалившемуся браузеру, или БД, или неожиданно долгому коннекту, прерванному по таймауту.
Если у вас отваливается БД — значит, у вас упал тест. Все нормально, так и должно быть. Следите за своей БД, это помогает.
Локальный прогон — это совсем не то же самое, что прогон на репозитории, он помогает только при идеальной дисциплине.
0
+12
Я предпочитаю большинство действий делать при помощи MSBuild'a, а TeamCity только запускает нужный таргет.
Таким образом, я могу из командной строки сделать любое действие над проектом — прогнать тесты, сделать бекап базы, обновить базу, обновить сайт в ИИСе,…
Таким образом, я могу из командной строки сделать любое действие над проектом — прогнать тесты, сделать бекап базы, обновить базу, обновить сайт в ИИСе,…
+1
Статья очень, очень хорошая, но не могу не вставить свои пять копеек.
— Про версии сборок. Хочу обратить внимание, что у 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 стали требовать).
Что думаете по этому поводу?
— Про версии сборок. Хочу обратить внимание, что у 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 стали требовать).
Что думаете по этому поводу?
+5
Здорово, что разворачивается дискуссия в комментах.
Достаточно много разработчиков, к сожалению, никогда не заглядывает в файл проекта. Я думаю, что важно научиться пользоваться msbuild и редактировать проект не только из студии, но и «ручками», потому что многих вещей из студии просто не сделать.
Про публикацию служб. Для доставки бинарников на сервер подходит тот же MSDeploy. Если в проекте уже используется MSDeploy для публикации web-приложений, то одной командой sync в MSDeploy можно скопировать все бинарники сервиса на целевой сервер. Шаред-папка и FTP это уже не модно :)На целевой машине может не быть IIS
— Параметры в TeamCity. Учите людей плохому. Кучу аргументов через /P указывать в TeamCity не надо — работать будет, но будут warnings. Специально для этого есть Build Parameters, они прозрачно транслируются в MSBuild скриптМожет у нас разные настройки TeamCity, я не видел ворнингов, хотя последние большие сборки у меня публиковались с помощью кастомного мсбилда, в который передается только конфигурация и никаких параметров нет.
Я больше склоняюсь к использованию PowerShell и конкретно psake. Это императивные скрипты, а не декларативный XML как в MSBuild, их не надо компилировать, можно легко править и можно отдать поддержку этих скриптов админам (от них сейчас знание PowerShell стали требовать).Никто же не мешает использовать и то и другое или что-то одно по вкусу. Главное, чтобы работало и было просто поддерживать. например, поэтому я чаще всего не пишу отдельные таски, чтобы не тащить за собой бинарники.
Достаточно много разработчиков, к сожалению, никогда не заглядывает в файл проекта. Я думаю, что важно научиться пользоваться msbuild и редактировать проект не только из студии, но и «ручками», потому что многих вещей из студии просто не сделать.
0
Версионирование продукта
На мой взгляд удобнее всего использовать msbuild и проставлять значение с помощью CI-сервера:
Как решается обратная задача? Пользователь репортит о проблеме, указывает версию продукта (скажем, посмотрев свойства dll'ки в Проводнике): 3.14.159.2. Как узнать, какой ревизии в репозитории соответствует эта версия сборки? Используется DVCS, где для идентификации ревизий применяется 1) немонотонный 20-байтный уникальный идентификатор, и 2) автоинкрементный, но неоднозначный номер (может различаться для одной и той же ревизии в разных клонах репозитория).
0
Ну, «правильный» способ — это использовать билд-репозиторий, где по версии можно получить бинарники, информацию о билд-процессе (а так же тестах и продвижении), ну и информацию о том, из чего именно эта версия была собрана.
0
Это означает выделение «избранного» репозитория. Хотелось бы, чтобы клоны были по возможности равноправны, чтобы каждый клон имел всю необходимую информацию, чтобы локального репозитория было достаточно для определения ревизии по версии.
0
Идете в TeamCity или в другое CI-решение, которое используете. Находите билд, соответствующий вашей сборке. Для того, чтобы иметь какое-то соответствие, TeamCity предлагает BuildNumberFormat. Вы можете настроить его в соответствие с версионированием вашего приложения.
0
Не могу не упомянуть опенсорсный CI-сервер CruiseControl.NET. У нас он работает в связке с Redmine.
0
Для автоматического изменения версий сборок есть еще подход, описанный здесь (основан на использовании build feature «AssemblyInfo patcher»).
Из преимуществ — сам изменяет номера сборок во всех AssemblyInfo.cs в солюшене, не надо править .csproj как описано в этой статье. Из недостатков — изменяет номера сборок для всех проектов в солюшене, т.е. не позволяет для разных проектов вести различное версионирование.
Из преимуществ — сам изменяет номера сборок во всех AssemblyInfo.cs в солюшене, не надо править .csproj как описано в этой статье. Из недостатков — изменяет номера сборок для всех проектов в солюшене, т.е. не позволяет для разных проектов вести различное версионирование.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Continuous Integration для самых маленьких