📌Техпроцессы. Определение и важность CI/CD📌
После того как Вы задумали разработку собственного продукта и определились с технологиями, необходимо задуматься, по каким правилам будет идти разработка и как же разрабатываемый продукт будет доставляться в релиз с каждой новой версией.
Хорошо бы сделать этот процесс максимально стабильным и автоматизированным.
Приоткроем завесу закулисья как этого добиться и постараемся сделать так, чтобы понял новичек или просто любитель IT технологий. И сразу с места в карьер.
Для параллельной работы над проектом нескольких разработчиков используются git репозитории. Если простыми словами - место где находится исходный код вашего проекта. При разработке системы управления проектами eTIME мы пользуемся подходом GitFlow, который в нашем случаем подразумевает наличие трёх веток исходного кода и трёх стендов проекта: dev, beta, master.
"Почему 3?" - Резонно спросят те, кто никогда не занимался разработкой.
- dev - тестирование работоспособности отдельных новых функций
- beta - общее тестирование всего функционала с целью выявления багов. Так называемые регрессионные и смоук тесты, которые проводят QA-инженеры.
- master - релизная версия приложения
Каждое изменение кода разработчиком оформляется в виде MR (merge request) в основную ветку и проходит предварительное ревью коллег. Важно соблюдать этот процесс для сохранения чистоты кода. По завершении спринта (1-2х недельная итерация разработки) все изменения отправляются на следующий стенд и так до прода.
Это не единственный подход, каждая команда ищет свой путь самурая. Да и с течением времени он может меняться...хоть самурай и не одобрил бы.
Существует так же подход деплоя с использованием одной лишь master ветки, который мы так же практиковали на крупных проектах, так называемый "one artefact deployment", но, честно признаться, мы так и не оценили его преимуществ.
Помимо разработки, проект еще надо разворачивать на сервере и регулярно обновлять. Это можно делать вручную либо автоматизировать этот процесс.
Эту ответственность на себя берет CI/CD. Что же это такое и для чего оно необходимо вашему проекту.
CI (Continuous Integration) упаковывает, проверяет сборки запуском функциональных и интеграционных тестов и оповещает разработчиков, если что-то пошло не так.
CD (Continuous Delivery) автоматически разворачивает приложения и выполняет дополнительные тесты, как правило это UI тесты.
CI/CD-конвейеры прекрасно подходят для частого внесения изменений в проекты с надежным процессом доставки в релиз. Внедрение CI/CD позволяет разработчикам сосредоточиться на улучшении приложений и не тратить силы на его развертывание.
Наша команда пользовалась такими средствами для настройки CI/CD как Jenkins, Azure Devops, TeamCity. При разработке eTIME сейчас используем последний, разворачивая наш продукт в docker контейнерах на сервере.
Итоговый процесс нашего CI/CD выглядит так:
- Процесс деплоя запускается вручную по кнопке. Ручной контроль запуска позволяет избежать попадания случайных изменений на стенд. Хотя можно настроить и на мерж в ветку.
- Далее происходит автоматическое подтягивание изменений проекта из git репозитория и этап сборки приложений.
- После чего запускается проход юнит тестов. Автоматическая проверка серверного функционала приложения. Важно не забывать писать теств или даже разрабатывать продукт на основе TDD - написание функционала через тесты.
- В случае их успешного выполнения разворачивается и запускается приложение на стенде и обновляется бд посредством применения новых миграций. Мы используем Fluent Migrator и Postgres базу данных.
- В конце запускаются UI тесты. В нашей команде их написание происходит при помощи Selenium.
- И в завершении процесса - проверка функционала QA-инженерами.
Надеюсь было полезно
и Вы еще на один шаг приблизились к пониманию процесса разработки собственного продукта и стали на шаг ближе к Вашей мечте.
...Продолжение следует...
#разработка #управлениепроектами #IT #github #jira #eTime