Transcription
Привет. Сегодня поговорим о таком процессе, как CCD. Почему это сейчас очень популярно, кому это нужно и как это настраивать.
Что такое CCD? CICD - это CI (Continuous Integration) и CD (Continuous Deployment). CI - это практика, при которой разработчики поставляют свои изменения в общую ветку кода. Каждый такой комит автоматически запускает процесс сборки и выполнения тестов. Это позволяет быстро найти какие-то конфликты и ошибки в коде, не дожидаясь конца спринта.
CD - это следующий шаг. Когда код уже проверился, он собрался и подготавливается к развёртыванию в продакшн среде. Однако саморазвёртывание может быть не только автоматическим, но и ручным, например, после опровом лида либо менеджера.
Например, я как разработчик сделал новую фичуку, добавил новую страничку в моём приложении. Локально весь функциал у меня работает, но после того, как я залил в гит, мой pйплайн упал. Pipйплаine - это автоматизированный процесс, в котором происходит сборка и выполнение тестов приложения. Допустим, пайплайн упал из-за того, что сборка приложения не собралась. Всё из-за того, что была ошибка в Тайпскрипте. После того, как я увидел, что у меня ошибка, я её пофиксил, залил заново в гиIT и Pipeline прошёл успешно.
Давайте разберёмся, как это работает поэтапно.
Первый этап - это разработчик пушит свой код, допустим, GitLab либо GitHub.
Второй этап - Cerver детектит изменения и запускает Pipeline. Cerver - это, например, Jenkins либо GitLub CI.
Третий этап - сборка. Код компилируется либо упаковывается в зависимости от языка.
Четвёртый этап - это тестирование. запускаются юнит-тесты, интеграционные тесты и различные проверки кода, принтеры.
Пятый этап - сборка артефактов. Если тесты успешно пройдены, создаётся готовый пакет, например, doкер в образ.
И шестой этап - деплой. CD-часть доставляет артефакт на сервер. Например, либо на Stage, либо продакш.
Почему этот процесс очень важен и полезен?
Раньше релизы делали очень редко. Весь код заливали ручками по FТП. Это приводило к множеству проблем. Самая частая проблема - это конфликты в коде. Один разработчик делал своё локально, другой своё. После того, как они мёрзжились, начинались проблемы, конфликты в одних и тех же файлах, если тем более они были какие-то корневые.
Вторая проблема - это человеческий фактор при деплой. Когда вы будете делать всё это ручками, у вас возникнет множество проблем, потому что вы можете что-то забыть, пропустить какой-то шаг. Когда процесс будет автоматизирован, всё гораздо проще и понятнее. Ручной деплой приводил к множеству проблем. Допустим, человек мог залить просто не ту версию кода.
И третья проблема - это долгий фидбэк. Когда вы залили код с помощью CCD, вы уже можете его сразу отсмотреть, и тестировщик может взять в тест вашу задачу. Раньше же тестировщики получали код большими кусками, что затягивало весь этот процесс, и обратная связь была гораздо дольше.
CD весь этот процесс улучшился, код проверяется сразу. Если вы залили что-то нерабочее, автоматические тесты проверят и вам скажут об этом.
Второй плюс - это автоматизация. Вам не нужно каждый раз настраивать сервер, собирать вручной билд и это всё заливать потом ручками.
И третий плюс - это быстрые и частые релизы. В больших компаниях релизы происходят практически ежедневно. И чтобы показать какой-то код, демозаказчику нужно этот процесс автоматизировать.
Давайте поговорим, кто участвует в этом процессе CCD и кто вообще ответствен за настройку всего этого.
CCD - это командная работа. Разработчики пишут код и дальше заливают его в GIT. Девопсы настраивают архитектуру и оптимизируют пайплайны. Тестировщики тестируют код и добавляют интеграционные и endнтесты. Менеджеры или тимледы контролируют весь этот процесс, чтобы он ускорялся, а не замедлялся.
Давайте поговорим о подобных камнях и сложностях этого подхода.
Первая сложность - это сложность настройки. Настройкой занимается DevOps, и ему главное, чтобы весь процесс был автоматизирован и очень хорошо сделан, потому что в седи достаточно большое количество процессов. Допустим, вы забыли запустить runр или что-то такое, и всё, процесс будет не настроен. Если плани описан неправильно, он будет падать и выдавать ошибки, что замерит разработку.
Вторая сложность - это ресурсы. Допустим, у вас в команде 10 разработчиков, и все что-то пилят, все что-то добавляют, все запускают сборку. В этом случае у вас могут быть конфликты, поставки, и сервер может просто не выдержать. Всеми этими процессами, естественно, занимается DevOps и ответственность лежит на нём.
Третья сложность - это сама культура разработки. Если команды не пользуются этим процессом, игнорируют тесты, сборку, линтинг, то весь этот процесс CCD теряет смысл.
Давайте разберёмся, почему CCD вообще так популярен.
Первое - это скорость доставки. Ваш код может моментально попасть на ваш продакшн-сервер и показать заказчику какой-то демо.
Второе - это качество кода. Если у вас настроены тесты, литинг, это помогает быстро найти ошибки.
Третье - это экономия денег и ресурсов, потому что ручные деплои стоят гораздо дороже, чем автоматически.
Четвёртая причина - это стабильность. Если у вас есть на проекте версионирование, вы достаточно быстро можете откатить неработающий код.
CCD - это вообще must have для современной разработки, особенно если проект средний или большой. Вначале, конечно, сложно это всё настроить, все вот эти тесты, сборки, всю эту систему, инфраструктуру, но в дальнейшем это ускоряет разработку.
Если хочешь быстро подготовиться к фронт-собеседованию и увеличить свою зарплату, заходи на мою платформу, где собраны все вопросы, которые задают на собеседовании по фронтенду. Есть записи собеседований, а также статьи по софтскилам от опытной чарки и тренажёр, в котором ты можешь потренироваться. Заходи. Доступ на 2 недели всего 900 руб.
Также давайте разберём на реальном проекте, как работает CCD на примере Gitlab CCD.
Вообще Gitlab CCD такой встроенный инструмент в Gitlab, который нам позволяет создать полный цикл пайплайна. То есть мы можем запустить тесты после каждого комита, мы можем автоматически выкладывать наше приложение на прот. Всё это будет происходить по тому сценарию, который вы сами описываете в самом гитлабе. С помощью него можно автоматически собрать проект на каждое изменение кода, запускать там различные тесты, юнит-тесты интеграционные, проверять качество кода за счёт линтинга, ну и подобное. Это всё происходит автоматически без какого-то ручного вмешательства, что помогает нам ускорить разработку. Ну и, соответственно, там уменьшает количество ошибок, которые мы могли бы совершить.
Одно из прикольных преимуществ Kitlaps CD, что мы можем одновременно посмотреть и код и запустить нашу сборку прямо в одном сервисе. То есть все приложения, все инструменты автоматизации находятся в одном месте, и там любой разработчик или DevObs инженер могут посмотреть, что произошло, и координировать свою работу. Это очень упрощает работы, ускоряет её, конечно, как и для крупных проектов, так и для небольших. Но в основном, конечно, этот процесс используют средние и крупные проекты.
Вообще GitLab CD бесплатный, вы можете его использовать до какого-то промежутка времени, что там 400 минут job можете спокойно использовать.
Основные понятия, о которых я буду говорить - это пайплайн, stage, джабы и раннеры. Ну, сразу скажу, что о раннерах здесь не будет глубоко рассказанно, так как это будет требовать отдельного ролика.
Давайте рассмотрим интерфейс GitLab CD и попробуем создать наш первый pipйлайн. Но для начала, конечно, я создам проект. Иду вот сюда, создаю пустой проект. Я создам проект своей платформы. Можно выбрать, э, приватный либо публичный, это как вы уже хотите. Также я жму галочку инициализировать Redmi File, то есть это стандартный Redmi файлик от Gitlab. И сразу создаю файлик GitLab Cam.
Что я буду в нём писать? Сначала я напишу STG. Stage - это специальные этапы, которые задействованы в пайплане. Я напишу по стандарту три этапа стейджа. Сначала это установка зависимостей, потом сборка проекта и дальше плои на defевер.
Дальше я начну описывать сами stage, например, install dependencies. И, соответственно, я укажу сам stage stage install. Для примера я напишу, что у меня будет выполняться какой-то скрипт, и я просто выполню эча и выведу, что у меня сейчас этап установки зависимости.
Следующий этап - это шаг сборки проекта. То есть это build мой. Напишу build project, указываю stage stage build. И дальше пишу свой скрипт, который будет выполняться. Минус ча. Собираем проект. Эча. Сборка завершена.
И последний этап. Deploy to de. stage deploy dev и соответственно scриpt что о том, что я вывожу плой на сервер.
И давайте попробуем это всё закоммитить и посмотреть. Идём, смотрим наш пайплайн и смотрим, что он застрял. Написано, что он застрял. Почему? Почему он застрял? А он нам пишет, что у вас нету активных ранеров для этого проекта. Можно перейти в C settings и выбрать runнер. У меня уже раннер настроен. Здесь я не буду обсуждать, как его настраивать. То есть я просто его уже подключу, который у меня есть. Всё, я подрубил его. Давайте посмотрим, запустилось или нет. Отменим пайплайн и запустим заново. И посмотрим, что с ним произошло. Дальше заходим. написано, всё равно у него нету активных раннеров. Почему так? Давайте обратно перейдём в C settings и посмотрим, что у меня есть вот этот раннер, да, он сотнен для моего апликейшна, и у него есть вот такой тег white. То есть для чего это нужно? То есть это тот раunнер специальный, который запускает мою джабу, который будет в дальнейшем запускать проект фронтен. То есть, чтобы ранее работал, нужно добавить специальный тег вот этот. Поэтому переходим обратно в наш Camel и редактируем. И добавляем на каждую стадию к и пишем минус white. То есть у меня ранер так называется. Я вот добавляю таким образом. И пишем update. Переходим дальше и смотрим, что у нас всё заработало. Соответственно, всё выполнилось, весь пайплайн прошёл. Давайте посмотрим вообще, что там получилось. Как мы видим, э здесь есть определённые команды, да, которые выполнялись, и мы видим то, что мы выводили устанавливаем зависимости и пишем готово. Соответственно, JБА выполнилась. Дальше идём в build и смотрим, что там тоже всё выполнилось. Всё у нас вывелось. То есть таким образом будет вообще работать пайплайн.
Давайте разберём, как будет устроен процесс на реальном проекте. Я скачаю себе проект, склонирую его себе и вижу, что у меня уже есть Redmi файл. Сейчас я добавлю файлы своей платформы и запушу их. Я добавил свои файлы, смотрю, что у меня добавилось. Соответственно, у меня добавился мой проект, и изменилась измишка. Я это всё добавлю и загомичу.
[музыка]
[музыка]
Я всё закомитил. Теперь проект в моём Gitрепозитории. Дальше я буду донастраивать фалик C. Что я буду делать? Соответственно, я опишу, как мне установить зависимости и как мне сбедить проект. Что мне нужно для этого делать? Соответственно, мне для этого нужно изменить скрипт. Какой скрипт будет на этой стадии? Я пишу yarн install frozen lock file. Это означает, что я хочу, чтобы ян установил мои пакеты, но только по ярнлоку. И для билда, соответственно, я пишу yarn build, указываю, что это будет defка. Но также не забываю, что эту сборку мне нужно потом раскатать, чтобы она перешла на следующий этап. Поэтому я пишу таким образом. Я пишу артефакт. указываю пути, чтобы он мне сохранил вот эту папку на следующую стадию, чтобы я потом мог раскатать это и, соответственно, закомичу это.
У меня начали устанавливаться зависимости. Можно посмотреть, происходит ярстал, то, что мы описали команду. И, соответственно, Яр начинает устанавливать нужные нам пакеты, которые находятся в package logy.
Во время записи у меня упал пайплайн. Я начал разбираться, в чём проблема. Соответственно, мы можем посмотреть при билде произошла какая-то ошибка здесь. началась сборка и что-то начало падать. В принципе, я посмотрел, оказалось, что я добавил нотмодули прямо в проекте, запушил и не посмотрел на это. Соответственно, я удалил модули и потом начал смотреть, что дальше. Дальше опять произошла какая-то ошибка. Сборка начала ругаться на то, что у меня якобы нету типов и в чём-то проблема при сборке происходит. Что сделал я? Я сделал, что перед сборкой перед сборкой каждый раз будет удаляться нот-модули. Я добавил такую инструкцию before script. Происходит удаление нодмодулем и, соответственно, заново всё устанавливается.
Как мы можем посмотреть текущий пайплайн? Всё сбилдилось, всё произошло. Мы можем посмотреть текущий билд. Вот он текущий билд реального проекта. Мы можем видеть, э, что в папке дис находится индекс HTML, ну и, соответственно, там JS, CSS файлы.
Также давайте разберём пример, как будет действовать CCD, если наша сборка не прошла и у нас есть какая-то ошибка в билдем. Допустим, я хочу сделать ошибку в Тайпскрипте. Я сделаю ошибку, что вместо строки у меня будет число. Как видим, TypeescriptриP подсвечивает, что у меня есть ошибка. И давайте посмотрим, произойдёт ли билд. У меня билд не происходит. Мы видим, что у нас есть тайпскритовые ошибки вот здесь. Теперь давайте попробуем залить это всё на Git и посмотрим, сбилдит ли приложение или не сбилдит CCD. Смотрим, произошёл комит, где я меняю со строки на число и произойдёт ли тут сборка. Сейчас посмотрим. Мы видим, что первая стадия прошла, а вот на второй стадии сборка не прошла. Build failed. Давайте посмотрим, что там не так. И мы видим, как раз у нас всё выдалось, что сборка не происходит из-за ошибки в тайпскрипте. И нам подсказывают конкретную ошибку, что не так и что где нам нужно исправить. Даже нам строку подсказывает. Можем зайти посмотреть, что тип строка не соотносится с таким типом number. И чтобы заново собрать проект, нам нужно пофиксить эту ошибку. Соответственно, байплан завершился на этом. Мы видим, что он фейлит, и он дальше не пошёл на следующую стадию. Таким образом, работает ICD на суперпростом примере.
Подписывайтесь на канал, ставьте лайки и делитесь комментариями, используете ли вы CCD в своей работе.