Как работает непрерывная интеграция и непрерывная доставка (CICD).

Если вы слышали о CICD и задавались вопросом, что это значит или как работает весь процесс, эта статья прольет свет на ваше понимание.

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

Непрерывная интеграция просто означает процесс внесения изменений в код в центральный репозиторий несколько раз в день.

Непрерывная поставка просто относится к процессу переноса небольших интегрированных изменений в производственную среду (продукт, используемый клиентами).

Если вы являетесь бизнес-менеджером по продукту в команде разработчиков программного обеспечения, вам, вероятно, следует совершить прогулку по комнате, потому что CICD сократит время вывода на рынок любой функции, которую вы собираетесь встроить в свой продукт.

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

Что я на самом деле имею в виду? Большинство команд, создающих программное обеспечение без CICD, сталкиваются с общими ловушками, особенно при интеграции обновлений в работающее программное обеспечение. Все становится очень сложно, могут возникнуть ошибки, которые может быть трудно отследить и устранить, может произойти неожиданное поведение, оставив разработчиков без понятия, и все это сводится к плохому опыту работы с клиентами, они отрекаются от вашего приложения и продолжают свою мирную жизнь.

Непрерывная интеграция и непрерывное развертывание создают удобный способ переноса кода с компьютера разработчика на работающий сервер, который обслуживает приложение, с которым взаимодействуют конечные пользователи. Теперь позвольте мне разбить его для вас.

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

Например, у нас есть команда разработчиков программного обеспечения, состоящая из 4 разработчиков, которые намерены создать приложение для продажи автомобилей. Первый шаг — просмотреть документ с бизнес-требованиями и создать пользовательские истории, чтобы охватить все варианты использования. Затем разработчики могут выбрать язык(и) программирования для использования при создании всего проекта. Далее, если это PHP-приложение, разработчики могут выбрать Laravel или Falcon. На данный момент созданы пользовательские истории и настроен фреймворк, все выглядит отлично.

Затем команда создает репозиторий на Github и делает первоначальную фиксацию новой установки только что загруженного приложения Laravel. Легкий как ветерок, CICD все еще идет хорошо.

Теперь истории появляются в инструменте назначения задач и отслеживания, таком как Pivotal Tracker, Asana или Trello. Разработчики врываются и подбирают истории, кодирование началось.

Слышал о слове TDD до? если это аббревиатура, которая смутила вас в прошлом, я искренне извиняюсь за удар, это было непреднамеренно. Простыми словами, разработка через тестирование (TDD) означает, что целостность вашего кода проверяется некоторым модульным или интеграционным тестом, который вы написали еще до того, как начали писать основной код для этой функции. Это включает в себя сначала написание модульного теста для проверки конкретной вещи, прежде чем писать основной код для этой конкретной вещи. TDD можно легко объяснить по сравнению с проверкой формы. Когда вводится неверный ввод или вводятся неправильные учетные данные, форма отказывается отправляться, и пользователь никогда не входит в систему. В Test Driven Development вы пишете проверки для своего кода в форме модульных тестов, и если ваша реализация реального кода не проходит тесты. , коммиты разработчиков никогда не будут развернуты на серверах.

Почему я потратил время на объяснение TDD, потому что он служит основной опорой в жизненном цикле CICD. Качество ваших тестов и уровень вашего тестового покрытия служат привратником для интеграции кода, и если ваш тест плохой, код с ошибками все равно может быть интегрирован.

Теперь, когда у нас есть TDD, мы можем продолжить наш поток CICD. Чтобы быть уверенным, позвольте мне повторить, до сих пор каждый из 4 разработчиков может фиксировать в одном и том же репозитории, они также совместимы с TDD, поскольку они пишут тесты качества, прежде чем они напишут фактическую реализацию.

Затем нам нужно интегрировать сервер сборки CI (Continuous Integration), который может автоматически запускать все тесты, написанные разработчиками с момента начала работы над проектом. Приложения контроля версий, такие как Github и Bitbucket, могут интегрироваться с несколькими серверами непрерывной интеграции, такими как Circle CI, Travis Ci, Drone или конвейеры bitbucket, и это лишь некоторые из них. Не забывайте, что серверы CI помогают нам запускать тест непосредственно в репозитории и требуют, чтобы мы поместили специальный файл .yml в корневой каталог репозитория проекта. Этот файл .yml содержит инструкции о том, как сервер CI будет создавать приложение и тестировать код. Конфигурация файла .yml зависит от используемого CI-сервера, но обычно они чем-то похожи, просто прочитайте их документацию.

Теперь, с передовой практикой TDD и сервером непрерывной интеграции, напрямую связанным с нашим репозиторием, нам нужно сопоставить наши ветки с различными средами.

Слышали ли вы о словах, средах производства, подготовки и разработки. Если нет, то я не собирался снова тебя бить. Не пугайтесь, это просто означает, что одно и то же приложение, которое создает команда, было развернуто в 3 разных местах с разными URL-адресами.

Например:

(Среда разработки)

(Промежуточная среда)

(Производственная среда)

В вашем репозитории Github вам нужно будет создать 3 отдельные ветки, например, development, staging, master.

Сопоставление будет выполнено в файле .yml, каждый сервер CI имеет документацию по настройке файла .yml. Но обычно они вообще дают вам возможность писать инструкции для любого количества веток в вашем репозитории.

Пример:

ветка: ** разработка:

-выполнить тест

-push код на сервер разработки

филиал: **постановка:

-выполнить тест

-push код на промежуточный сервер

ветка: **мастер:

-выполнить тест

-push код на рабочий сервер

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

Также обратите внимание, что для этих специальных ветвей рекомендуется запретить прямую отправку и разрешить только слияние. Это обеспечит структурированный подход к тому, как ваш код будет развернут в любой из сред.

Например:

Ветка разработки будет объединена с промежуточной, а затем промежуточная будет объединена с основной. Ни один из разработчиков ни в коем случае не сможет напрямую перейти к любой из этих 3 специальных веток, вместо этого они создают другие ветки и объединяются в разработку. Develop становится единственным источником правды, который будет распространяться на другие ветки.

Когда группа контроля качества проведет приемочное тестирование промежуточной среды и найдет ее стабильной, они могут дать положительный отзыв, и коммиты будут объединены в мастер, чтобы изменения/новые функции были развернуты для конечных пользователей.

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