Непрерывные интеграция, поставка и развертывание

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

Непрерывная поставка – это использование автоматизированной системы для выполнения непрерывной интеграции вместо ручного вмешательства (которое отнимает много времени и чревато ошибками). Непрерывная поставка обычно рассматривается как использование конвейерного программного обеспечения для интеграции и развертывания кода на протяжении всего жизненного цикла разработки системы. Конвейерное программное обеспечение, также известное как CI/CD (от англ. Continuous Integration / Continuous Delivery), интегрирует новый код в ствол кодовой базы, проверяет его компиляцию, публикует его в различных тестовых средах, выполняет разнообразные автоматизированные тесты и предоставляет обратную связь на каждом этапе этого процесса. Системы непрерывной поставки имеют фантастические эффективность, повторяемость и качество. Невозможно запускать сотни тестов вручную, если код нужно проверять 10 раз в день. Конвейерное программное обеспечение облегчает данную задачу.

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

СОВЕТ. Использование конвейера CI/CD – не единственное условие выполнения программы DevOps. Как вы узнаете далее в этой главе, DevOps представляет собой намного больше, чем просто ПО для конвейера.

Dev(Sec)Ops

Чтобы говорить о DevSecOps, сначала необходимо обсудить DevOps. Существует множество определений DevOps, однако я придерживаюсь того, которое приводится в DevOps Handbook и The Phoenix Project (упоминавшихся в главе 7).

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

Внедрить методологию DevOps в работу можно тремя путями, о которых говорится в The Phoenix Project.

Первый путь внедрения DevOps заключается в обеспечении эффективности всей системы. Необходимо концентрироваться не только на своей части системы, а рассматривать весь жизненный цикл разработки в целом и вносить в него улучшения, тем самым обеспечивая быстрые и надежные результаты. Здесь подразумевается использование автоматизации (включая программное обеспечение CI/CD) и других процессов и инструментов, делающих возможным ускоренный релиз кода.

Второй путь внедрения DevOps – обеспечение быстрой обратной связи. Недостатком каскадного метода было отсутствие обратной связи в течение нескольких месяцев, что часто вело проектные команды по неправильному пути: они создавали не тот проект, который на самом деле был нужен клиенту или отвечал его потребностям. Это также приводило к тому, что тестирование и другая обратная связь касательно безопасности откладывались до самого позднего этапа жизненного цикла разработки системы, когда вносить исправления было уже очень дорого и сложно, а времени на это почти не оставалось. Быстрая обратная связь означает автоматизацию различных видов проверок, включая тестирование безопасности. Здесь также очень полезен конвейер CI/CD. Однако любая автоматизация процесса тестирования безопасности или обратной связи будет соответствовать требованиям второго пути даже без использования конвейерного программного обеспечения.

СОВЕТ. Одним из способов обеспечить очень быструю обратную связь с разработчиками является добавление тестов безопасности в модульное тестирование. Похожего эффекта можно добиться с помощью оболочек библиотек, меняя имена небезопасных функций на такие, как «небезопасныйМD5Hash-нетрогать» или «вотпочемуунасвсеплохо».

Третий путь DevOps – постоянное обучение, эксперименты и принятие риска. Третий путь подчеркивает необходимость постоянно работать над повышением качества и эффективности повседневной работы сотрудников. Кроме того, он включает в себя метрики и другие измерения, показывающие направление движения рабочей деятельности. О тенденциях развития технологий в сфере безопасности можно узнавать, например, в процессе обмена мнениями в обеденное время и на занятиях, курсах, посредством книг и других материалов. Проверка концепции (PoC) различных инструментов или технологий с целью выяснения, какой из них лучше всего отвечает потребностям организации, – один из способов убедиться в актуальности и полезности выбранного для работы инструмента. Очень важно, чтобы каждую неделю или каждый месяц выделялось определенное количество времени на улучшение ежедневной работы.

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