ProHoster > блог > интернет вести > 3 популярных инструмента для организации непрерывного развертывания (Continuous Deployment)
3 популярных инструмента для организации непрерывного развертывания (Continuous Deployment)
Continuous Deployment (непрерывное развертывание) — особый подход в разработке программного обеспечения, который применяется для быстрого, безопасного и эффективного внедрения различных функций в ПО.
Основная идея — создание надежного автоматизированного процесса, позволяющего разработчику быстро предоставлять пользователю готовый продукт. При этом вносятся постоянные изменения в продакшн — это называется конвейером непрерывной доставки (CD Pipeline).
Потсетуваме:за сите читатели на „Хабр“ - попуст од 10 рубли при запишување на кој било курс Skillbox користејќи го промотивниот код „Хабр“.
Для управления потоком можно использовать широкий ряд инструментов, среди которых есть как платные, так и полностью бесплатные. В этой статье описываются три самых популярных среди разработчиков решения, которые могут оказаться полезными каждому программисту.
Џенкинс
Полностью автономный сервер автоматизации с открытым исходным кодом. С ним стоит работать для автоматизации всех видов задач, связанных со сборкой, тестированием, поставкой или развертыванием программного обеспечения.
Минимални барања за компјутер:
256 МБ ОЗУ, 1 ГБ файлового пространства.
Оптимально:
1 ГБ ОЗУ, 50 ГБ на жестком диске.
Для работы понадобится еще и дополнительное программное обеспечение — Java Runtime Environment (JRE) версии 8.
Архитектура (распределенные вычисления) выглядит следующим образом:
Jenkins Server — установка, которая отвечает за GUI-хостинг, а также организацию и выполнение всей сборки.
Jenkins Node/Slave/Build Server — устройства, которые можно настроить для выполнения работы по сборке от имени Master (главного узла).
Установка для Linux
Сначала нужно добавить репозиторий Jenkins в систему:
После этого Jenkins будет доступен в системе по дефолтному порту 8080.
Для проверки работоспособности нужно открыть в браузере адрес localhost:8080. Затем система предложит ввести начальный пароль пользователя с root-правами. Этот пароль находится в файле /var/lib/jenkins/secrets/initialAdminPassword.
Теперь все готово к работе, можно приступать к созданию потоков CI/CD. Графический интерфейс рабочей среды выглядит следующим образом:
Сильные стороны Jenkins:
масштабируемость, которую обеспечивает архитектура Master/Slave;
наличие REST XML/JSON API;
возможность подключения большого числа расширений благодаря плагинам;
активное и постоянно развивающееся сообщество.
Конс:
отсутствует аналитический блок;
не слишком удобный интерфейс.
Тимски тим
Коммерческая разработка от компании JetBrains. Сервер хорош простой настройкой и отличным интерфейсом. В дефолтной конфигурации есть большое количество функций, постоянно увеличивается число доступных плагинов.
Для работы требуется Java Runtime Environment (JRE) версии 8.
Требования сервера к железу некритичные:
ОЗУ — 3,2 ГБ;
процессор — двухъядерный, 3,2 ГГц;
канал связи с пропускной способностью 1 Гб/с.
Сервер позволяет достичь высокой производительности в работе:
60 проектов с 300 конфигурациями сборок;
выделение 2 МБ на журнал сборки;
50 агентов сборки;
возможность работы 50 пользователей в веб-версии и 30 пользователей в IDE;
100 подключений внешней СКВ, как правило, Perforce и Subversion. Среднее время изменений — 120 секунд;
более 150 модификаций в день;
работа с БД на одном сервере;
настройки серверного процесса JVM: -Xmx1100m -XX:MaxPermSize=120m.
Требования к агенту обусловлены работающими сборками. Основная задача сервера — отслеживание всех подключенных агентов и распределение сборок из очереди по этим агентам на основе требований совместимости, с сообщением результатов. Агенты имеют различные платформы и операционные системы, плюс предварительно сконфигурированную среду.
Вся информация о результатах сборки хранится в базе данных. В первую очередь это история и другие подобные данные, изменения VCS, агенты, очереди сборки, учетные записи и разрешения пользователей. В базу не входят лишь журналы сборки и артефакты.
Установка для Linux
Для ручной установки TeamCity с контейнером сервлета Tomcat следует использовать архив TeamCity: TeamCity .tar.gz. Загрузить его можно отсюда.
tar -xfz TeamCity.tar.gz
/bin /runAll. sh [start|stop]
При первом запуске нужно выбрать тип БД, в которой будут храниться данные о сборке.
Конфигурация по умолчанию работает на localhost:8111/ с одним зарегистрированным агентом сборки, запущенным на том же ПК.
Сильные стороны TeamCity:
простая настройка;
лесен интерфејс;
большое количество встроенных функций;
служба поддержки;
есть RESTful API;
неплохая документация;
хорошая защищенность.
Конс:
ограниченная интеграция;
это платный инструмент;
небольшое сообщество (которое, впрочем, растет).
GoCD
Open source-проект, для установки и работы которого требуется Java Runtime Environment (JRE) версии 8.
Системски побарувања:
ОЗУ — 1 ГБ минимум, лучше больше;
процессор — двухъядерный, с частотой работы ядра 2 ГГц;
жесткий диск — минимум 1 ГБ свободного места.
Агент:
ОЗУ — минимум 128 Мбайт, лучше больше;
процессор — минимум 2 ГГц.
Сервер обеспечивает работу агентов и предоставляет удобный интерфейс для пользователя:
Stages/Jobs/Tasks:
Установка для Linux
ехо "деб download.gocd.org /” | sudo tee /etc/apt/sources.list.d/gocd.list
возможность пошагового отображения пути развертывания GoCD в одном представлении:
отличное отображение структуры конвейера:
GoCD оптимизирует рабочий процесс CD в самых востребованных облачных средах, включая Docker, AWS;
инструмент дает возможность исправлять неисправности в конвейере, для чего есть отслеживание каждого изменения от коммита до развертывания в realtime-режиме.
Конс:
нужен хотя бы один агент;
нет консоли для отображения всех выполненных задач;
для выполнения каждой команды нужно создавать по одной задаче к конфигурации конвейера;
для установки плагина требуется переместить файл .jar в <go-server-location>/plugins/external и перезапустить сервер;
относительно небольшое сообщество.
Како заклучок
Это всего три инструмента, на самом деле их гораздо больше. Выбирать сложно, поэтому обязательно нужно обращать внимание на дополнительные аспекты.
Открытый исходный код инструмента дает возможность понять, что он из себя представляет, плюс быстрее добавлять новые функции. Но вот если что-то не работает, то приходится надеяться лишь на себя и на помощь комьюнити. Платные инструменты предоставляют поддержку, которая может порою оказаться критически важной.
Если безопасность важнее всего, стоит работать с локальным инструментом. Если же нет, то выбор SaaS-решения — хороший вариант.
И последнее: для того чтобы обеспечить действительно эффективный процесс непрерывного развертывания, нужно сформировать критерии, специфика которых даст возможность сузить круг выбора доступных инструментов.