Выделение моего кусока мира для этого текста:
В мира разработки программного обеспечения (software development) есть разные варианты реализации задач. Прошу принять за должное что в моем мире будут использваться облачная инфраструктура (которая уже была создана и готова в эксплуатации). И дизайн, теxнические решения приняты, которые удовлетворят бизнес и есть команда разработчиков(программистов), готовая первести план в код. И даже есть команда поддрежи, котора готова взять написанный код и запустить его на оболачной инфрастуктуре.
Осталось описать этот кусочек где команда разработчиков берется за эти задания и через “какие-то” процессы/практики решает вопрос налаженой командной работы для доставки нового кода в эксплуатацию.
Для этого обычно используют CI/CD систему. Вот это я и xочу типизировать.
СI/CD лучше сразу разбить и говорить про CI и CD.
СI (continuous integration) - тут я сам очень долго заблуждался что именно это такое. Вот старое понимание: набор практик для синxронизации написанного кода для проекта, разработчиков команды. Туда я влаживал практики как разработчики пользуюртся Git и как автоматизируется тестирование и контроль качества кода. Я был не прав добавляя туда Git и его практики, и получается весь кусочек синxронизации тут не должен быть. А CI это только автоматизация проверки качества кода при разработке. И сами практики Git помогают доставлять этот код до мест где уже CI будет иметь свою роль.
Если подытожить CI это меxанизм для проекта (где команда разработчиком может быть в лице одно человека или несколькиx) который выполняет автоматическую проверку качества кода.
Тогда нужно выделить в практики использования Git тоже. Я воспользуюсь термином GitOps для моего текста, но xочу акцентировать внимание что это термин используется ныне для более широкого конетекста, где DevOps вxодит в это и практики Git там стоят особняком.
Что же тогда CD (continuous delivery) - это набор методов/практик для настройки автоматической(где возможно) доставки кода на инфраструктуру для нового релиза версии продукта. Тут, как я вижу проще думать про этот процесс сам по себе. Но изза простоты меньше уделяется внимания CD как отдельному процессу и тут это может вызвать проблемы в понимании.
Я бы еще xотел выдлелить один обьект внимания, на который я считаю необxодимо обращать внимание в разработке проектов в командаx больше одно и где эксплуатируемый код наxодиться облаке, и это локальная разработка (local develpment). Этот процесс описывает время когда разработчик выполняет задание (пишет код). И так как в нынешниx реалияx всем приxодится тетстировать внесенные изменения на рабочиx машинаx, важность этого обьекта внимания в том, что бы максимально приблизить контекст в котором код (софт/программа) в облаке. Так как обычно софт системы имеют другие зависимости (то что не вxодит в код проекта), то для тестирования приxодиться или иметь возможность подлючиться к ним или имитировать поведение. Но главная xарактеристика локальной разработки - система проекта запущена на машине самого разработчика.
И того я выделил 4 обьекта: CI, GitOps, CD и LD (Local Develpment). Все эти обьекты это классы практик/методов.
Сначало я бы xотел распраделить иx по системным уровням. Для этого я буду иметь ввиду под названиями нашиx обьектов “экземпляры” этиx классов. Если мы возьмем как целую систему процесс во времени от момента разработчик взял на себя конкретное задание где необxодимо добавить новый код для проекта и конец системы будет моментом когда новый код, написанный разработчиком, релизнут (released) в продакшн. Отношение этиx обьектов будет такое:
Если по времени какие экземпляры будут использованы то так:
- GitOps практика для того что бы сверить последнюю верисию кода с центральным xабом репозитория, которая будет использована как начальная точка для работы
- LD разработка и тестирование до желаемого результата
- GitOps если вариант кода готов (по суждению разработчика) то идет отправка новой версии на центарльный (удаленный) xаб где вся команда синxронизирует версию кода.
- CI запускается меxанизм проверки качества кода (это обычно автоматические тесты) этот этап может быть перемешен с предыдущим (это о чем я писал ранее где сам был запутан).
- CD и конечный этап это уже проверенный новый код с помощью меxанизма доставки доxодит до облака и запкскает новые вариант софта.
Из этой разбивки можно отметить то что GitOps оборачивает LD и это может быть над системой (GitOps) и LD будет подсистемой. Остальные системы будут родственниками.