Ниже приведен список наиболее важных требований для непрерывной интеграции.
Регулярная регистрация — Самая важная практика для непрерывной интеграции для правильной работы — это частая регистрация в магистральной или основной линии хранилища исходного кода. Регистрация кода должна происходить как минимум пару раз в день. Регулярная регистрация приносит много других преимуществ. Это делает изменения меньше и, следовательно, меньше шансов сломать сборку. Это означает, что последняя версия программного обеспечения, к которой следует вернуться, известна, когда в любой последующей сборке была допущена ошибка.
Это также помогает быть более дисциплинированным в отношении рефакторинга кода и придерживаться небольших изменений, которые сохраняют поведение. Это помогает гарантировать, что изменения, изменяющие множество файлов, с меньшей вероятностью будут конфликтовать с работой других людей. Это позволяет разработчикам быть более исследовательными, опробовать идеи и отказаться от них, вернувшись к последней версии.
Создайте комплексный автоматизированный набор тестов. Если у вас нет комплексного набора автоматических тестов, только промежуточная сборка означает, что приложение может быть скомпилировано и собрано. Хотя для некоторых команд это большой шаг, важно иметь некоторый уровень автоматического тестирования, чтобы обеспечить уверенность в том, что ваше приложение действительно работает.
Обычно в Continuous Integration проводится 3 типа тестов, а именно модульные тесты, тесты компонентов и приемочные тесты .
Модульные тесты написаны для проверки поведения небольших частей вашего приложения в изоляции. Обычно их можно запускать без запуска всего приложения. Они не попадают в базу данных (если она есть в вашем приложении), файловую систему или сеть. Они не требуют, чтобы ваше приложение работало в производственной среде. Модульные тесты должны выполняться очень быстро — весь ваш пакет, даже для большого приложения, должен быть запущен менее чем за десять минут.
Тесты компонентов проверяют поведение нескольких компонентов вашего приложения. Как и модульные тесты, они не всегда требуют запуска всего приложения. Однако они могут попасть в базу данных, файловую систему или другие системы (которые могут быть отключены). Тесты компонентов обычно выполняются дольше.
Сохраняйте процесс сборки и тестирования коротким — если сборка кода и запуск модульных тестов занимает слишком много времени, вы столкнетесь со следующими проблемами.
Люди перестанут делать полную сборку и будут запускать тесты до регистрации. Вы начнете получать больше неудачных сборок.
Процесс непрерывной интеграции займет столько времени, что к тому времени, когда вы сможете снова запустить сборку, должно было произойти несколько коммитов, поэтому вы не будете знать, какая регистрация прервала сборку.
Люди будут проходить регистрацию реже, потому что им придется сидеть целую вечность, ожидая, пока будет построено программное обеспечение и запущены тесты.
Не регистрируйте поврежденную сборку. Самым большим недостатком непрерывной интеграции является проверка поврежденной сборки. Если сборка не работает, ответственные разработчики ждут ее исправления. Они идентифицируют причину поломки как можно скорее и устраняют ее. Если мы примем эту стратегию, мы всегда будем в лучшем положении, чтобы выяснить, что вызвало поломку, и немедленно исправить ее.
Если один из наших коллег произвел регистрацию и в результате сломал сборку, то, чтобы иметь наибольшие шансы ее исправить, им потребуется четкое решение проблемы. Когда это правило нарушается, это неизбежно занимает гораздо больше времени для исправления сборки. Люди привыкли видеть сломанную сборку, и очень быстро вы попадаете в ситуацию, когда сборка остается сломанной все время.
Всегда выполнять все тесты коммитов локально перед фиксацией. Всегда проверяйте, что тесты, предназначенные для приложения, выполняются в первую очередь на локальном компьютере, прежде чем запускать их на сервере CI. Это делается для того, чтобы гарантировать правильность написания тестовых случаев и, если в процессе CI есть какой-либо сбой, это происходит из-за неудачных результатов теста.
Возьмите на себя ответственность за все поломки, возникшие в результате ваших изменений — если вы фиксируете изменение и все написанные вами тесты проходят, но другие ломаются, сборка все еще не работает. Обычно это означает, что вы ввели регрессионную ошибку в приложение. Вы несете ответственность — потому что вы внесли изменения — исправить все тесты, которые не прошли в результате ваших изменений. В контексте CI это кажется очевидным, но на самом деле это не распространенная практика во многих проектах.