Dev Easy Notes

Я планировал начать с пайплайнов, но решил: давайте сначала разберемся с самой аббревиатурой CI/CD. Фишка в том, что под этими аббревиатурами подразумевают уже не то, что изначально закладывалось. Сейчас при упоминании CI/CD в голове всплывают скорее системы GitLab CI, Actions, Kubernetes или Docker. Однако все эти системы на самом деле лишь вспомогательные инструменты.

Continuous Integration — постоянная интеграция. Возникает вопрос: интеграция чего во что? Мы все работаем с кодом и, вероятнее всего, работаем в какой-то команде. Когда мы делаем какие-то изменения, то должны эти изменения распространить на других участников команды, а также получить изменения от них.

Сейчас для этого повсеместно используется Git. У тебя есть локальная версия кода, изменения в которой ты отправляешь на удаленный сервер. Другими словами, ты "интегрируешь" свои изменения с изменениями других участников.

Понимаете суть? Если у тебя настроен Git и есть практика условно раз в день отправлять свои изменения и получать изменения от остальных членов команды, у тебя уже в некотором смысле есть CI.

Вокруг этой идеи затем строится процесс, чтобы правильно внедрить наши изменения: хорошо бы их сначала проверить — прогнать линтер, прогнать тесты, сделать сборку. Ну и еще перед интеграцией наших изменений, чтобы наша команда эти изменения просмотрела, отсюда мы получаем код-ревью.

Continuous Delivery — постоянное развертывание. Этот принцип уже исходит из следующей проблемы. Вот есть разработка, которая пишет код, создает систему. И есть команда, отвечающая за развертывание. Проблема в коммуникации между этими двумя группами: одна группа жалуется на "тупых админов", вторая — на "криворуких разработчиков".

Помимо этого, софт раньше поставлялся четкими версиями. Вот выпустили вы ПО версии 2, и все, ближайшие пару лет будете на ней сидеть. Ведь чтобы ее обновить, нужно, чтобы все самостоятельно обновились через покупку диска, либо, если мы говорим про серверы, админы накатили новую версию.

Разумеется, если ты сейчас будешь выпускать обновления раз в полгода, твой бизнес отправится по направлению нах*й. Отсюда рождаются два основных принципа:

👉 команда разработки должна участвовать в развертывании;
👉 наша кодовая база должна быть готова к развертыванию в любой момент времени.

Уже из этих принципов мы получаем подходы к работе с Git (православный trunk-based, а не загнивающий Git Flow), Docker, чтобы синхронизировать окружение разработки и развертывания, Kubernetes, чтобы он сам убрал старые инстансы и поднял новые, и все прочее, что относится к DevOps.

👍43❤10

www.tgoop.com/dev_easy_notes/435

2.82K viewsMay 28 at 06:47

Я планировал начать с пайплайнов, но решил: давайте сначала разберемся с самой аббревиатурой CI/CD. Фишка в том, что под этими аббревиатурами подразумевают уже не то, что изначально закладывалось. Сейчас при упоминании CI/CD в голове всплывают скорее системы GitLab CI, Actions, Kubernetes или Docker. Однако все эти системы на самом деле лишь вспомогательные инструменты.

Continuous Integration — постоянная интеграция. Возникает вопрос: интеграция чего во что? Мы все работаем с кодом и, вероятнее всего, работаем в какой-то команде. Когда мы делаем какие-то изменения, то должны эти изменения распространить на других участников команды, а также получить изменения от них.

Сейчас для этого повсеместно используется Git. У тебя есть локальная версия кода, изменения в которой ты отправляешь на удаленный сервер. Другими словами, ты "интегрируешь" свои изменения с изменениями других участников.

Понимаете суть? Если у тебя настроен Git и есть практика условно раз в день отправлять свои изменения и получать изменения от остальных членов команды, у тебя уже в некотором смысле есть CI.

Вокруг этой идеи затем строится процесс, чтобы правильно внедрить наши изменения: хорошо бы их сначала проверить — прогнать линтер, прогнать тесты, сделать сборку. Ну и еще перед интеграцией наших изменений, чтобы наша команда эти изменения просмотрела, отсюда мы получаем код-ревью.

Continuous Delivery — постоянное развертывание. Этот принцип уже исходит из следующей проблемы. Вот есть разработка, которая пишет код, создает систему. И есть команда, отвечающая за развертывание. Проблема в коммуникации между этими двумя группами: одна группа жалуется на "тупых админов", вторая — на "криворуких разработчиков".

Помимо этого, софт раньше поставлялся четкими версиями. Вот выпустили вы ПО версии 2, и все, ближайшие пару лет будете на ней сидеть. Ведь чтобы ее обновить, нужно, чтобы все самостоятельно обновились через покупку диска, либо, если мы говорим про серверы, админы накатили новую версию.

Разумеется, если ты сейчас будешь выпускать обновления раз в полгода, твой бизнес отправится по направлению нах*й. Отсюда рождаются два основных принципа:

👉 команда разработки должна участвовать в развертывании;
👉 наша кодовая база должна быть готова к развертыванию в любой момент времени.

Уже из этих принципов мы получаем подходы к работе с Git (православный trunk-based, а не загнивающий Git Flow), Docker, чтобы синхронизировать окружение разработки и развертывания, Kubernetes, чтобы он сам убрал старые инстансы и поднял новые, и все прочее, что относится к DevOps.

BY Dev Easy Notes