В этой статье мы решили немного рассказать об инструментах непрерывной интеграции (CI), которые мы используем в компании Дневник.
ру, и поделиться небольшими разработками в этом направлении.
Большая часть материала может показаться банальной рекламой выбранного CI-движка или попыткой развязать священную войну (и не одну), но это не было замыслом.
Статья также не является руководством или описанием каких-либо возможностей и может расцениваться как статья из шапки - главное, чтобы она была интересной и вызывала обсуждение.
Дженкинс
Одной из первых задач, которые я поставил перед собой, придя в компанию около 3 месяцев назад, было внедрение «нормальных» (с моей точки зрения) CI-практик.Не то чтобы в компании тогда не было подобной практики, но в то время в компании внедряли CI с помощью известного Дженкинс .
Это проект с открытым исходным кодом, который является ответвлением другого крупного инструмента CI — Хадсон .
Последний раз я работал с Хадсоном в 2008 году, и опыт был очень негативным.
Интерфейс меня не напугал, трудности настройки я смог пережить, но ситуация, когда в итоге все это падает и спотыкается на ровном месте по 20 раз в день, не стала для меня положительной характеристикой хорошо- проверенная стабильная система.
Как оказалось, время не лечит, и эти проблемы никуда не делись – даже спустя 4 года и смену имени.
Виновата основная идея и Хадсона, и Дженкинса — это просто наиболее обобщенные движки для CI. Их главная сила должна была заключаться в их расширяемости:
- Возьмем двигатель
- Устанавливаем тысячу плагинов на все случаи жизни
- Мы пытаемся все это настроить
- Как прибыль
Плагины обычно пишут другие люди, и вы понятия не имеете, насколько хорошо каждый из них протестирован, есть ли в коде что-то неожиданное — примеров масса.
Поэтому меня всегда забавляли люди, которые завешивали свои системы плагинами как новогодние елки, а потом ругали тормоза и вылеты в своих любимых: FireFox, Miranda, Visual Studio (добавляйте по вкусу).
Использование проверенных источников и принцип минимализма всегда спасали меня от подобных неприятностей.
К сожалению, в случае с Дженкинсом все было не так просто.
Изначально основанное на идее максимально обобщенного решения, но тем не менее принадлежащее миру Java, для мира .
Net оно из коробки не могло сделать абсолютно ничего.
Хотите собирать проекты .
Net? Установите сторонний плагин.
Вам нужна аутентификация LDAP? Установите сторонний плагин (про костыли для вытягивания адресов электронной почты из LDAP вообще молчу).
Даже Subversion не поддерживается «из коробки»; вам нужно снова установить другой плагин - сомнительного качества и с очень скудным набором функций.
В общем, все это вылилось в титанические усилия по настройке и поддержанию фермы плагинов (всего около 50).
И, как я уже отмечал, код может быть недостаточно протестирован, поэтому попытка обновить версию какого-либо плагина может легко привести к краху всего Jenkins. Неслучайно там предусмотрена возможность понижения версии прямо на странице управления плагинами (кнопка понижения версии у всех Jenkins тоже присутствует) — все это связано именно с проблемами стабильности и совместимости.
В результате проблемы со стабильностью, плохая инфраструктура мира .
Net, а также весьма значительные затраты на поддержку и администрирование сборок свели на нет все преимущества Jenkins как бесплатной CI-системы.
Команда Сити
Скажу сразу, долго не мучился с выбором двигателя.Я сразу понял, что буду использовать Командный город JetBrains .
Причины довольно просты:
- Я это очень хорошо знаю и много раз применял в процессе;
- Легко управлять;
- «Из коробки» есть все необходимое для .
Net-проектов;
- Отличная интеграция с IDE и средой разработки;
- Шаблонизатор проектов (этого катастрофически не хватало в Jenkins);
- Довольно удобная лицензионная политика Jet Brains: бесплатная Профессиональная версия Team City содержит всего два ограничения: 20 билд-проектов и 3 билда машин;
- Ну и прочие вкусности.
Здесь я сразу призываю всех любителей принять участие в Специальной Олимпиаде не воспринимать эту фразу буквально.
Я придаю этому более глубокий смысл.
Open Source — это хорошо и спасение для многих компаний, но суть всегда остается одной: open source решение в 90% случаев проиграет аналогичной коммерческой разработке.
Вот почему я даже не отвел взгляда CC.Net и другие.
Может возникнуть естественный вопрос: а почему не Atlassian Bamboo или TFS? Все очень просто.
Выбор TFS означало бы сжигание мостов для других технологий, а я не сторонник подобных мер и уверен, что наш проект очень скоро выйдет за рамки 100% .
Net-решения.
Да, его можно использовать и для других технологий, но только с использованием костылей и опять же потерей времени.
Atlassian Bamboo сам по себе неплох, отличная интеграция с Jira, хороший UX. Но отсутствие предкоммитных сборок и плохая интеграция со средой разработчика, отсутствие поддержки NuGet и прочие мелочи склонили чашу весов в пользу Team City. Будет удивительно, что внутри Team City использует тот же подход, за который я критиковал Jenkins/Hudson — это система плагинов, и весь ее функционал представлен исключительно плагинами.
Да, это так, но с одним исключением: все плагины, входящие в стандартный пакет TeamCity, протестированы JenBrains. На них влияет коммерческий характер продукта; они не могут позволить себе выбросить на рынок горстку изделий кустарного промысла.
За это люди платят деньги, а значит, требования гораздо жестче.
Плюс, что мне всегда нравилось в продуктах JetBrains, так это то, что словосочетание «пользовательский опыт» для них не пустой звук.
С самого начала они возьмут вас за руку и проведут через все тернии установки и администрирования с максимальным комфортом.
Я ценю такую заботу и считаю, что именно так и следует делать профессиональную продукцию.
Выполнение
Я не буду описывать процесс установки и настройки TeamCity; это не является целью данной статьи и не очень интересно.Скажу лишь, что я установил систему на Windows Server 2008 R2 и использовал MS Sql Server 2008 R2 в качестве базы данных.
Одна особенность быстро стала ясна.
В схеме базы данных для Ms Sql Server не везде поддерживается Unicode. Особенно это было заметно, когда разработчики писали комментарии к коммиту на русском языке.
Эту проблему было довольно легко решить.
В базе данных, в таблице vcs_history тип столбца описание был изменен с варчар (макс.
) на nvarchar (макс.
) .
Да, это может вызвать проблемы при обновлении на последующие версии, но это было необходимо.
Основная сложность заключалась не в настройке Team City, а в самих разработчиках.
Точнее, попытка заставить их воспринимать поломку CI-сборки как неординарное событие, которое следует немедленно исправлять.
Здесь может быть только один рецепт: тщательное документирование процесса и личный контроль исполнения.
Через какое-то время люди поняли, что от них требуется, и теперь мне даже не приходится это контролировать.
Первая установленная нами сборка — это обычная сборка интеграции решений .
Net. Чтобы более правильно понимать, кто именно провалил сборку и с чем, была настроена политика сбора сборки для каждого коммита в svn. Этого оказалось недостаточно, поскольку простая интеграционная сборка не проверяла ошибки компиляции Asp.Net. Немного обсудив эту тему, мы решили добавить новую конфигурацию во все проекты веб-приложений.
CI-сборка и напишите следующее цель в файлах проекта
Таким образом, каждый разработчик мог запустить компиляцию проекта Asp.Net перед его фиксацией.<Target Name="AfterBuild" Condition="'$(Configuration)' == 'CI Build'"> <AspNetCompiler VirtualPath="temp" Clean="true" PhysicalPath="$(ProjectDir)" /> </Target>
Возникла проблема с интеграционной сборкой.
Когда к нему добавили компиляцию Asp.Net, время полной сборки увеличилось с 3 минут до 20, что свело на нет все преимущества сборки для каждого коммита.
Нам нужно было получать сообщения об ошибках компиляции как можно быстрее и эффективнее.
Поэтому было решено разделить интеграционную сборку на 2 части:
- Компиляция Msbuild
- Компиляция Asp.Net
Вкратце это работает так:
- Сначала выполняется обычная интеграционная сборка проекта, как отдельная конфигурация сборки.
- В случае успеха запускается другая конфигурация сборки, выполняющая asp.net-компиляцию проекта, и она запускается на том же исходном снимке, на котором проводилась предварительная интеграционная сборка — т.е.
на той же исходной ревизии.
Таким образом, мы не обременяли машины ненужной компиляцией Asp.Net в случае сбоя интеграционной сборки.
И ошибки msbuild мы получали гораздо быстрее.
Помимо интеграционных сборок и запуска тестов, мы используем TeamCity для сборки установочных пакетов.
Встроенная система артефактов позволяет указать, что будет артефактом сборки, и при необходимости заархивировать его.
Эти артефакты можно загрузить непосредственно в пользовательский интерфейс.
Или получите его через REST API.
До TeamCity сборка пакета осуществлялась путем вызова сценария PowerShell, который просто использовал 7Zip и через командную строку указывал архиватору, какие типы файлов не следует включать в архив (поскольку количество типов файлов, которые необходимо включить в архив, архив был гораздо больше).
Поэтому система артефактов немного разочаровала.
Во-первых, ни один из встроенных архиваторов не показал хорошего соотношения сжатия/скорости по сравнению с 7Zip. Ближайшим был tar.gz, но совсем близко.
Во-вторых, в скрипте артефакта нельзя было прописать конструкции исключения определенных типов файлов из архива, что было крайне неудобно и вынуждало полностью выписывать все, что нужно было включить (за это, кстати, можно проголосовать).
К тому же размер архива был около 500 Мб, что заставило UI задуматься о вечном.
Мы похоронили идею использования системы артефактов и до сих пор используем PowerShell, благо в TeamCity есть для этого встроенный раннер.
NuGet
Одной из особенностей, которая меня очень заинтересовала, была объявленная поддержка сервера NuGet внутри TeamCity. Я давно подумывал о настройке корпоративного NuGet-сервера, чтобы прекратить бесконтрольное добавление зависимостей в проект и просто для внутренних библиотек, которыми было бы удобнее пользоваться через NuGet. Так что возможность использования для этих целей самого CI-движка — вместо общей папки в сети — показалась многообещающей.
TeamCity предоставляет два канала NuGet: один гостевой без аутентификации, второй с типом авторизации, установленным на TeamCity. 
Ленту можно подключить как в Visual Studio, так и в NuGet Restore Package (файл NuGet.targets), чтобы исключить возможность добавления новой зависимости втихаря.
<ItemGroup Condition=" '$(PackageSources)' == '' ">
<!-- Package sources used to restore packages. By default, registered sources under %APPDATA%\NuGet\NuGet.Config will be used -->
<!-- The official NuGet package source ( https://nuget.org/api/v2/ ) will be excluded if package sources are specified and it does not appear in the list -->
Теги: #непрерывная интеграция #.
NET #jenkins #team city #разработка сайтов #программирование
-
Серфинг, Но Будь В Безопасности
19 Oct, 24 -
Прибыль От Публикации Электронных Книг
19 Oct, 24 -
Я Студент Из .Masterhost
19 Oct, 24 -
Здравствуйте, Дорогие Друзья!
19 Oct, 24 -
Вещи, Которые Мы Хотим Сделать «Позже»
19 Oct, 24
