После того как Вы задумали разработку собственного продукта и определились с технологиями, необходимо задуматься, по каким правилам будет идти разработка и как же разрабатываемый продукт будет доставляться в релиз с каждой новой версией.

📌 Хорошо бы сделать этот процесс максимально стабильным и автоматизированным.

Приоткроем завесу закулисья как этого добиться и постараемся сделать так, чтобы понял новичок или просто любитель 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-инженерами.

Надеюсь было не сложно и Вы еще на один шаг приблизились к пониманию процесса разработки собственного продукта и стали на шаг ближе к Вашей мечте.