DEV_EASY_NOTES Telegram 435
Я планировал начать с пайплайнов, но решил: давайте сначала разберемся с самой аббревиатурой 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.
👍4310



tgoop.com/dev_easy_notes/435
Create:
Last Update:

Я планировал начать с пайплайнов, но решил: давайте сначала разберемся с самой аббревиатурой 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


Share with your friend now:
tgoop.com/dev_easy_notes/435

View MORE
Open in Telegram


Telegram News

Date: |

The optimal dimension of the avatar on Telegram is 512px by 512px, and it’s recommended to use PNG format to deliver an unpixelated avatar. Select “New Channel” As five out of seven counts were serious, Hui sentenced Ng to six years and six months in jail. Judge Hui described Ng as inciting others to “commit a massacre” with three posts teaching people to make “toxic chlorine gas bombs,” target police stations, police quarters and the city’s metro stations. This offence was “rather serious,” the court said. 5Telegram Channel avatar size/dimensions
from us


Telegram Dev Easy Notes
FROM American