Что такое непрерывная интеграция (CI) и чем она полезна? [закрыто]

Может кто-нибудь объяснить мне концепцию непрерывной интеграции, как она работает в понятной форме? И почему компания должна использовать CI в своем рабочем процессе доставки кода? Я разработчик, и моя компания (в основном команда разработчиков) использует Team City. Как разработчик, я всегда проверяю, обновляю и фиксирую код в SVN, но мне никогда не приходилось беспокоиться о TeamCity или CI в целом. Поэтому я хотел бы понять, в чем польза КИ? Является ли CI частью гибких методологий?

Непрерывная интеграция в двух словах означает, что вы сохраняете свою работу, помещаете ее в систему управления документами (в вашем случае SVN), все тесты запускаются автоматически (как модульные, интеграционные, функциональные и т. Д. Тесты), так и приложение компилируется и подготавливается. для доставки (т.е. ISO образ создан). Непрерывная интеграция отличается от непрерывной доставки. Доставка по-прежнему осуществляется в разные моменты. CI гарантирует, что продукт может быть доставлен в случае необходимости, не более того.

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

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

КИ обычно ассоциируется с гибкими методологиями, однако я лично не знаю точную историю КИ.

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

Для этого требуется полностью автоматизировать процесс сборки приложения, а также автоматизированный набор тестов и сервер, который создает текущее состояние кода и запускает набор тестов на нем. Это должно происходить ежедневно или даже после каждой проверки кода.

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

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

У вас может быть определенный стиль в разработке: вы извлекаете, кодируете, компилируете, проверяете, проклинаете, меняете, компилируете, подбадриваете, делаете коммит. Вы фиксируете только рабочий код, возможно даже менее детально, как в конце рабочего дня или когда функция завершена. Вы проверяете свои зависимости всякий раз, когда импортируете библиотеки API.

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

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

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

Есть два аспекта непрерывной интеграции.

1. Стратегия управления исходным кодом разработки гарантирует, что разработчики могут постоянно интегрировать свою текущую работу с другими разработчиками стабильного кода.
2. Автоматическое создание и тестирование исходного кода, инициированное фиксацией в контроле исходного кода

Точка 1 является критической. Это движение к частым и малым по своей природе слияниям, которые делают разработчики с большей вероятностью успешными.

Точка 2 - это инструменты и инфраструктура, которые необходимы для обеспечения безопасности точки 1, быстрого выявления слияний, которые потерпели неудачу из-за нарушения существующего кода.

Насколько это полезно?

Невероятно. Как разработчик, работающий над проектом, он позволяет вам тратить большую часть своего времени на то, что вы делаете, и не беспокоиться о параллельной работе остальной команды. Когда ваша текущая работа завершена, вы публикуете свои изменения в остальной части команды, и в течение следующих нескольких часов они объединят ваши изменения с текущей работой.

Без этого разработчики делают слияния большого взрыва. Обычно они занимают несколько дней своей работы и объединяют ее со всеми изменениями, внесенными остальной частью команды за один раз. Когда слияние происходит заметно плохо, другой разработчик, вероятно, переходит на другую работу и начинает забывать мелкие детали, чтобы помочь разобрать беспорядок слияния. Что еще хуже, без постоянного построения и тестирования, пока код компилируется, ошибки слияния могут появляться в коде и не будут обнаружены, пока тестирование (или клиенты) не обнаружат их.

CI полезен, когда у вас есть:

• Компиляция кода
• Актуальный набор тестов
• Отчеты, основанные на исходном коде (покрытие кода, нарушение стандартов кода и т. Д.)
• Процедура, которую вы делаете периодически, после того, как код успешно скомпилирован

Список можно продолжить ..