Этот пост был первоначально опубликован в нашем корпоративном блоге здесь
Уильям Вергара, гибкий фасилитатор в Atlanticsoft.
Самая ранняя и непрерывная доставка ценности клиенту создает большие проблемы для групп разработки программного обеспечения. Строительство функциональных возможностей, которые материализуют такую ценность, предполагают, что несколько часов работы, распределенных среди членов команды. В конце процесса разработки каждый член вносит свой индивидуальный вклад в общий репозиторий; вызывая функциональность. Время для выполнения этой интеграции будет пропорционально размеру команды и сложности развития; Задержка доставки клиенту. Этот способ работы неэффективен и в конечном итоге вносит большие изменения и реже, чем предполагает команда.
Одним из возможных решений является непрерывная интеграция. Тем не менее, важно понимать, что непрерывная интеграция является практикой, а не использование и реализация сервера интеграции; Это будет последний шаг процесса принятия.
Интеграция в основной репозиторий Каждое небольшое изменение уменьшает возможность ошибок. Кроме того, идеальным состоянием будет автоматически запускать набор тестов, чтобы убедиться, что конструкция не нарушена.
Внедрение этого способа работы создает большие проблемы для команды и организации. Поскольку непрерывная интеграция — это практика разработчика, выполняемая ежедневно или более раз в день, важно сосредоточиться на людях В результате, каждая отдельная интеграция в основной репозиторий заставляет систему растет; В то же время, что репозиторий остается готовым развернуть, если это необходимо.
Каковы проблемы?
Изменение менталитета и поведение членов команды
Естественно предполагать, что интеграция является одним из последних шагов, которые должны выполняться только до конца разработки, результаты будут проверены; Предоставление разработчику уверенность и безопасность для интеграции его работы. Чтобы избежать такого поведения; Важно изменить размер задач до меньшего размера, таким образом, тестирование, обнаружение ошибок и их коррекция будет проще и быстрее.
Направление разработчика выполнять максимальное фракционирование их задач, способствует их принятию этой практики. Точно так же, сделав их вклад видимым через несколько интеграций в течение дня, укрепит мотивацию и уверенность команды.
Правильное управление версиями
Поскольку основной репозиторий является священным, оно должно быть максимально чистым, поэтому важно управлять версиями в качестве резервного копирования безопасности перед интеграцией. Репозиторий содержит исходный код и файлы конфигурации; Так что обязательно включите последнюю версию кода, которая работает правильно.
Обеспечить интеграцию приращений (решения), а не ошибки
Очевидно, что результаты тестов помогают решить этот момент, но Какие тесты должны быть выполнены?
Существуют разные типы тестов, и каждый из них сосредоточен на другой стадии развития цикла. Все они важны, и только производительность набора может привести к высокой степени надежности. В соответствии с Майк Кон Тест Пирамида , он устанавливает заказ, количество усилий, указанных типом теста, скорости выполнения и затрат.
В нижней части пирамиды мы находим модульные тесты. На этом тесте методы и классы проверяются независимо, поэтому их объем ограничен. Интеграционные и приемлемые тесты составляют уровень обслуживания, интеграционные тесты подтверждают, что несколько компонентов вместе имеют ожидаемое поведение, которое может включать другие услуги. Вместо этого приемочные тесты сосредоточены на деловых случаях. Наконец, тесты пользовательского интерфейса проверяют операцию с точки зрения пользователя.
Поскольку тестирование подразумевает стоимость во время разработки, лучше покрывать как можно больше с помощью модульных тестов, которые быстрее создавали и выполняют. Кроме того, этот вид теста может дать быстрому обратную связь для разработчика, избегая ввода ошибок с начала цикла разработки.
Настройка сервера интеграции
Во время первых запусков можно будет запустить набор полных тестов, но по мере того, как продукт выращивает тестирование становится сложным. Важно сохранить последовательность и убедиться, что проверки данных организуются должным образом для предоставления быстрой информации разработчику и правильной среде для выполнения. Убедитесь, что ядро продукта была идентифицирована и полностью протестирована.
В любое время сохранение зеленого здания
Наибольшим приоритетом во время процесса будет идентифицировать и исправить, если сборник основной ветви сломается с какой -либо интеграцией. В противном случае, было бы сложнее понять дальнейшие перерывы, и наверняка это представляет больше недостатков.
Обычно впадает в практику задержки интеграции, чтобы не нарушать сборку. Напротив, постоянная интеграция помогает определить ошибки и понять ее причину и его быстрое исправление. Принятие этой практики также помогает учиться в процессе, оставляя те же ошибки в прошлом. Создание многофункциональной команды и постоянное сотрудничество ее членов помогут на данный момент. Основная практика для реализации — это Разработка на основе багажника.
Почему непрерывная интеграция приводит к техническому совершенству?
Техническое превосходство можно рассматривать как набор из трех компонентов: техника, навыки разработчика в технике и чувства разработчиков команды. Эти аспекты необходимы и обязательны в процессе принятия непрерывной интеграции.
Как только команда сосредоточится на своей работе на минимальной единице работы и придерживается набора автоматических тестов, она направляет усилия по расширению охвата модульными тестами в продукте. Эта практика приведет к применению проектных шаблонов для достижения низкой связи и высокой сплоченности на компонентах. В результате он позволяет создавать репозиторий с многократно используемыми компонентами, включая автоматический набор тестов.
Кроме того, команда будет иметь место и возможность экспериментировать с развивающимися модульными тестами в Тестовая разработка (TDD) ; в том числе таким образом тесты с самого начала разработки. Другая возможность будет включить рядом с TDD, Развитие поведения (BDD) также включить приемные тесты из самой разработки.
Процесс принятия интеграции включает в себя реализацию серии методов членами команды. Постоянная практика таких методов укрепит навыки и чувство команды и приверженности.
В заключение
Принятие непрерывной интеграции оптимизирует время развивающегося цикла путем немедленного выявления и разрешения конфликтов. В результате количество времени, затрачиваемого на исправление ошибок, будет посвящено формированию хорошего набора тестов.
Интегрируя небольшие изменения, область применения уменьшается; позволяя команде коллективно понимать конфликты и постепенный рост самого продукта. Обмен знаниями между разработчиками мотивируется процессом, поскольку изменения легче переваривать.
В Atlanticsoft Как последователи Agile Manifesto, мы внедряем непрерывную интеграцию. Благодаря этой практике мы помогаем нашим клиентам оптимизировать стоимость и время, производя более стабильные решения.
Использованная литература:
https://martinfowler.com/bliki/testpyramid.html https://codeship.com/continoury-integration-essentials https://martinfowler.com/articles/continouryintegration.html
Оригинал: «https://dev.to/atlanticsoft/adopting-continuous-integration-as-a-route-to-technical-excellence-mk0»