💡С чего всегда надо начинать разработку. Часть 1. CI pipeline
Многие современные проекты начинаются с реализации кода, затем подготовки бизнес-требований, затем адаптации уже написанного кода к этим требованиям, а потом начинается процесс превозмогания инфраструктурных проблем: как собирать приложение, какие тесты выполнять и как это сделать, как и куда развертывать приложение, и многое другое.
Конечно, в этот список можно расширять бесконечно и все это будет правильно и справедливо и все это про "ad-hoc хаос".
Проблема в том, что реализацию проектов начинают с обратной стороны, при этом упуская фундаментальные вещи, которые проще всегда закладывать в самом начале. "Вы же не закладываете фундамент после крыши, верно?"
Как инженеры разработки современного ПО, перед началом реализации любых требований, мы в первую очередь должны побеспокоится о базовых вещах, облегчающих нам жизнь и повышающих эффективность и качество работы.
Вот мой минимальный адаптивный список, успешно применяющийся на проектах с которыми мне приходится работать и после чего команда начинает разработку:
1. Создание код-репозиторий
2. Continuous Integration pipeline
- сборка проекта (любая ветка)
- выполнение unit-тестов (любая ветка)
- упаковка docker image (основная ветка)
- загрузка собранных артефактов в хранилище (основная ветка)
3. Интеграция код-репозитория и CI-pipeline
- тригер на выполнение п.2 при изменениях в код-репозитории
- отражение фактического результата сборки на графических приборах
- уведомление о проваленной сборке
Про Continuous Delivery pipeline поговорим в следующем выпуске.
Макс Добрынин
@maksymdobrynin
Многие современные проекты начинаются с реализации кода, затем подготовки бизнес-требований, затем адаптации уже написанного кода к этим требованиям, а потом начинается процесс превозмогания инфраструктурных проблем: как собирать приложение, какие тесты выполнять и как это сделать, как и куда развертывать приложение, и многое другое.
Конечно, в этот список можно расширять бесконечно и все это будет правильно и справедливо и все это про "ad-hoc хаос".
Проблема в том, что реализацию проектов начинают с обратной стороны, при этом упуская фундаментальные вещи, которые проще всегда закладывать в самом начале. "Вы же не закладываете фундамент после крыши, верно?"
Как инженеры разработки современного ПО, перед началом реализации любых требований, мы в первую очередь должны побеспокоится о базовых вещах, облегчающих нам жизнь и повышающих эффективность и качество работы.
Вот мой минимальный адаптивный список, успешно применяющийся на проектах с которыми мне приходится работать и после чего команда начинает разработку:
1. Создание код-репозиторий
2. Continuous Integration pipeline
- сборка проекта (любая ветка)
- выполнение unit-тестов (любая ветка)
- упаковка docker image (основная ветка)
- загрузка собранных артефактов в хранилище (основная ветка)
3. Интеграция код-репозитория и CI-pipeline
- тригер на выполнение п.2 при изменениях в код-репозитории
- отражение фактического результата сборки на графических приборах
- уведомление о проваленной сборке
Про Continuous Delivery pipeline поговорим в следующем выпуске.
Макс Добрынин
@maksymdobrynin