Как выбрать облачную CI/CD платформу?

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

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

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

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

На каждом этапе компакт-диска есть варианты быстрого возврата к старой версии и создания отчетов об ошибках, которые разработчики могут включить в новую версию. Цель состоит не в том, чтобы запускать несколько сборок в производство, а в том, чтобы постоянно настраивать и улучшать программное обеспечение без регрессии. Другой термин для этих практик — «devops».

Почему стоит размещать CI/CD в облаке?

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

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

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

Также возможно развертывание CI/CD на гибриде локальных и облачных серверов. Некоторые из последних предложений CI/CD работают в контейнерах на кластерах Kubernetes, которые могут работать одновременно локально и в облаке. В сценарии гибридного развертывания вы можете разместить каждый компонент там, где это наиболее целесообразно, принимая во внимание физическое расположение самих разработчиков и сетевое расположение других серверов в инфраструктуре разработки.

CI/CD должен интегрироваться с репозиториями организации

Репозитории необходимы для CI и CD. Помимо того, что репозитории программного обеспечения являются конечной точкой процесса регистрации и тестирования, они являются предпочтительным местом для хранения сценариев CI и CD, а также файлов конфигурации. Да, многие платформы CI/CD могут хранить сценарии и другие файлы внутри, но обычно лучше иметь их в системе управления версиями вне инструмента.

Почти все инструменты CI/CD могут работать с Git. Некоторые также напрямую интегрируются с GitHub, GitHub Enterprise, GitLab и/или Bitbucket. Некоторые из них также поддерживают Subversion и/или Mercurial.

Инструменты CI/CD должны поддерживать используемые в компании языки программирования и инструменты
Каждый язык программирования или языковая группа (языки JVM, компилируемые языки LLVM, языки.NET и т. д.) имеют свои собственные инструменты сборки и тестирования. Чтобы быть полезным для вас, инструмент CI/CD должен поддерживать все языки, которые являются частью данного проекта. В противном случае вам может потребоваться написать один или несколько плагинов для инструмента.

Образы Docker становятся все более важными для распределенного, модульного и микросервисного развертывания программного обеспечения. Это нормально, если выбранный вами инструмент CI/CD работает с образами Docker, включая создание образа из вашего исходного кода, двоичных файлов и предварительных условий, а также развертывание образа в определенной среде. Если вы этого не сделаете, вам может потребоваться написать плагины или сценарии для реализации необходимых вам функций Docker. Точно так же инструмент CI/CD должен поддерживать Kubernetes и другие системы оркестрации контейнеров, которые мы используем в наших средах.

Выбирайте разные инструменты CI/CD для разных проектов

Ошибочно полагать, что одна платформа будет оптимальной для всех проектов по разработке программного обеспечения. В большинстве магазинов используется несколько языков программирования и сред, и не каждая платформа CI/CD будет хорошо их поддерживать.

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

Планируйте будущие миграции CI/CD

Точно так же давайте не будем предполагать, что данная платформа CI/CD будет вечно служить потребностям наших проектов. Лучше обезопасить себя, например, храня скрипты в репозиториях, а не в инструменте CI/CD.

По возможности отдавайте предпочтение бессерверной CI/CD

Как правило, развертывание облачных контейнеров дешевле, чем развертывание экземпляра облачного сервера, а бессерверное облачное развертывание дешевле, чем развертывание контейнеров. Бессерверный означает, что контейнер, в котором запущен интересующий процесс, инициируется при необходимости, обычно в ответ на событие. В случае CI/CD инициирующим событием обычно является проверка кода в определенной ветке репозитория; Затем веб-перехватчик репозитория запускает бессерверный процесс. Когда процесс завершается, ресурсы освобождаются.

Одной из немногих сред CI/CD, которые могут запускать бессерверные процессы, является Serverless CI/CD, часть Serverless Framework Pro, расширенной версии Serverless Framework с открытым исходным кодом. Бессерверная CI/CD оптимизирована для развертывания бессерверных приложений и в настоящее время работает только на AWS. Вам нужно будет определить, достаточно ли хорошо он поддерживает ваше приложение, чтобы его можно было использовать.

Где находятся наши облачные ресурсы?

Для оптимизации облачной установки CI/CD (или любого облачного приложения) полезно, если все наши ресурсы находятся «близко» друг к другу. «Близко» в этом контексте относится частично к географическому местоположению и частично к местоположению в сети. Например, если наша база данных находится в Австралии, а приложение — в Северной Америке, это будет вызывать длительную задержку каждый раз, когда приложению потребуется прочитать или записать данные.

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

Точно так же, если наша база данных находится на Google Cloud Platform, штат Вирджиния, а приложение — на Microsoft Azure, штат Вирджиния, задержка будет выше, чем если бы обе они находились на одном и том же облачном провайдере в одной и той же зоне доступности. Все это также относится к репозиторию (который, по сути, является базой данных), программному обеспечению CI/CD, самому приложению, а также разработчикам и тестировщикам. Лучше, если все будут «рядом», хотя эффекты задержки в этой ситуации не так бросаются в глаза, как это было бы, скажем, в интерактивной игре в реальном времени.

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

Сделайте доказательство концепции, прежде чем совершить

После завершения внедрения CI/CD станет важной частью нашей инфраструктуры.

Перед началом разработки конвейеров CI/CD важно завершить тщательное подтверждение концепции. Часть CI должна быть протестирована до начала фазы CD.