En

JazzTeam Software Development Company

Agile Java Development

Как внедрить CI/CD на проекте с историей своими силами. Часть 1: подготовительный этап

Введение

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

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

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

Так как на проекте не было CI и автотестов, то тестирование и развертывание производилось вручную. Как следствие, возникали проблемы:

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

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

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

Подготовка к внедрению CI/CD

Вначале мы составили следующую документацию к проекту:

Ниже мы рассмотрим эту документацию подробнее.

После разработки документации DevOps инженер приступил также к практическим работам по проверке концепции. В рамках данной задачи было сделано следующее:

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

  1. Внедрение CI/CD стоит начинать сразу после первичного анализа и составления технического задания. Так как во первых существует риск того, что внедрение CI/CD так и останется техническим долгом – а команда при этом получит состояние выученной беспомощности, а во вторых внедрение CI/CD это долгий процесс, и результат будет не очень скоро, только когда наберется критическая масса обновлений. Поэтому лучше сразу выделять время на работу с техническим долгом и через некоторое время этот подход окупится сторицей.
  2. Внедрять CI/CD лучше мелкими инкрементами. Тогда команда сможет почувствовать результат, получить необходимый опыт и быструю обратную связь, что позволит достичь лучшего результата.
  3. В процессе работы был применен опыт, приобретенный в рамках другого проекта. Было проведено демо по применению скриптов на Groovy в CI/CD на Jenkins. Это стратегия нашей компании, когда опыт, полученный на одном из проектов суммируется и передается на другие проекты, позволяя таким образом пользоваться экспертизой не только конкретных инженеров проекта, а всей компании целиком.

Фидбек вспомогательного менеджера проекта:

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

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

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

Как гласит японская пословица: быстро двигаться – это двигаться медленно, но постоянно.

Фидбэк от основного менеджера проекта:

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

Диаграмма развертывания

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

Deployment_diagram
Диаграмма развертывания

Анализ среды окружения

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

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

На проекте мы всегда анализируем среды окружения по следующей структуре:

Важно, чтобы список был полным с точки зрения ключевых компонентов процесса обновления системы. По каждому пункту необходимо дать описание:

Диаграмма процессов взаимодействия

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

Test_interaction_process_diagram
Диаграмма процессов взаимодействия Test
Live_Interaction_Process_Diagram
Диаграмма процессов взаимодействия Live

Диаграмма интеграции CI/CD

Проанализировав текущую ситуацию поставке продукта, мы разбили всю систему на атомарные операции и объединили их в пайплайн. Атомарные операции это базовые операции, которые может выполнять Jenkins в нашей системе, такие как остановка сервера, копирование данных, операции с системой контроля версий и т.п. Из этих базовых операций в дальнейшем строится весь процесс CI/CD.

CI_CD_Integration_Diagram
Диаграмма интеграции CI/CD

Прочие документы

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

Заключение

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

, , , , , ,

Comments are currently closed.