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

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

Это было захватывающе ... в худшем случае.

У компании, назовем ее ABC Corp, было 16 экземпляров одного и того же программного обеспечения, каждый из которых был размещен на разных компьютерах с ОС Linux на отдельных машинах Linux в их центре обработки данных. В итоге я наблюдал (в течение 3 часов), как клиент удаленно подключался к каждой машине индивидуально и выполнял «развертывание capistrano». Для тех, кто не знаком, Capistrano - это, по сути, инструмент для создания сценариев, который позволяет удаленно выполнять различные задачи. Процесс развертывания включал запуск нескольких команд на каждой машине, а затем ручное тестирование, чтобы убедиться, что она работает.

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

В ту ночь я пошел домой и не мог уснуть.

Одним из моих любимых занятий на работе всегда было автоматизировать себя без работы, как бы банально это ни звучало. Я изо всех сил стараюсь следовать мантре «Не делайте ничего вручную более одного раза». Развертывания - это первое, что, по моему мнению, должна автоматизировать каждая команда, и одна из первых вещей, над которыми мы работали в ABC Corp, используя конвейер сборки для реализации непрерывной интеграции и непрерывной доставки. Вот почему:

Непрерывная интеграция

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

Идея проста:

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

В результате команда видит, как проект реагирует на каждую фиксацию независимо от размера. Когда что-то пойдет не так, вы можете точно увидеть, какая фиксация вызвала сбой, и, вероятно, какая именно строка кода это сделала. Непрерывная интеграция - один из лучших способов сохранить как можно меньше изменений кода, за что выступает движение DevOps, а не за большие изменения. Это также означает, что в случае нескольких сред (Разработка, Тестирование, Интеграция, Производство и т. Д.) Среды должны быть максимально похожи друг на друга.

Непрерывная доставка

Непрерывная доставка, известная как CD, относится к автоматизации развертывания кода, который успешно прошел через ваш набор тестов.

«По сути, это практика выпуска каждой хорошей сборки для пользователей» - Джез Хамбл

Реализация следующая:

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

Учитывая, что все развертываемые изменения представляют собой отдельные коммиты, развертывания имеют низкий риск и вызывают меньше ошибок, но это также означает, что вы, как бизнес, можете разрабатывать и развертывать код очень быстро и так часто, как захотите. Сочетание этого с контейнеризацией (например, Docker, K8s), особенно на облачной платформе, обеспечивает очень быстрое развертывание и минимальное время простоя, что означает, что команда может развернуть его в любое время дня.

Почему это важно?

Если посмотреть на четыре ключевых показателя разработки программного обеспечения, которые, как они определены в Accelerate, о которых я говорил здесь, являются единственными показателями, которые имеют значение при измерении производительности и эффективности команды разработчиков программного обеспечения. Хорошие практики CI / CD могут существенно улучшить оценку команды.

  1. Время выполнения: CI / CD позволяет разработчику завершить написание кода и развернуть изменение непосредственно в производственной среде, где пользователь имеет к нему доступ. Это может произойти в течение нескольких часов или даже нескольких минут, если у команды есть хорошие практики CI / CD.
  2. Частота развертывания: более быстрые и небольшие развертывания означают, что команда может развертывать и будет развертывать их чаще, особенно если в развертывании нет ничего особенного. Вспомнив ABC Corp., представьте, насколько больше команда была готова к развертыванию, когда все, что требовалось, - это нажатие кнопки, что любой мог сделать в любое время. Во всех командах Amazon по всему миру они развертываются в среднем каждые 11 секунд.
  3. Среднее время восстановления: сценарий - команда внедряет изменение, которое вызывает перерыв. Благодаря отличным методам CI / CD команда точно знает, какое изменение и даже какие строки вызвали проблему. Спустя 15 минут исправление было разработано и развернуто в производственной среде.
  4. Частота сбоев при изменении: небольшие изменения в сочетании с ранней и часто интеграцией ваших сервисов и полным запуском вашего набора тестов означают, что критические изменения обнаруживаются еще до того, как они попадут в рабочую среду. . Весь код, который попадает к пользователям, был протестирован. Остались только скрытые ошибки, которые появляются каждую синюю луну.

То, что нужно запомнить

Когда команда пытается внедрить и реализовать практики CI / CD, при разработке они должны помнить несколько вещей.

При правильном использовании CI / CD может стать отличным инструментом для всех команд разработчиков программного обеспечения. Никто не хочет тратить несколько часов на наблюдение за запуском сценария после выполнения «capistrano deploy», надеясь, что ничего не пойдет не так, если они могут просто отправлять код каждый день и быть уверенными, что они будут предупреждены, если что-то пойдет не так.

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

Вы можете использовать любой из популярных CI-серверов (Concourse, Jenkins, GoCD, Circle-CI и многие другие), чтобы помочь получить невероятные результаты и позволить разработчикам работать над сложными проблемами, одновременно улучшая программное обеспечение. устойчивость.

CI / CD - один из самых простых шагов, которые можно предпринять для внедрения современных методов разработки программного обеспечения, поэтому, как заявляет Nike:

Спасибо за прочтение!

Другие статьи из моей серии о современных практиках разработки программного обеспечения можно найти здесь

РЕСУРСЫ: