Блог

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

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

Обычно, когда вы сохраняете свой код ежедневно, чтобы быть уверенным, что ваша работа не будет потеряна.

С другой стороны, CI или непрерывная интеграция предназначены для проверки того, все ли в порядке с тем, что вы создали, в большинстве проектов CI не применяется к отдельным ветвям, т.е.: feature , bugfix , Он применяется к основным ветвям master develop , т.Е.: , releases , и т.д. И эти ветки не обновляются ежедневно, поскольку для их обновления требуется запрос на извлечение и кто-то для утверждения этого запроса на извлечение.

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

Итак, возобновляя, да, вам нужно ежедневно фиксировать свой код, но вам не нужно ежедневно применять к нему CI.

Я предлагаю вам проверить рабочий процесс Gitflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Ответ очевиден.

1. Фиксация кода: как правило, код фиксируется только после локального тестирования в среде. Подумайте Developer_A о том, чтобы поработать над Component_A , следовательно, нужно совершить с минимальной проверкой, поскольку область применения заключается в разработке Component_A. Нет, представьте себе сложную систему с разработкой 50 разработчиков Component_B … Component_Z Если кто-то выполняет код без минимального теста, это, скорее всего, даст вам неудачный результат.

Или же разработчик может зафиксировать его в ветке разработки, что все вместе зависит от стратегии SCM, адаптированной в проекте.

2. Продолжение области тестирования интеграции: с другой стороны, интегратор в основном собирает и объединяет различные коды (программные компоненты) вместе в 1 контейнер и выполняет разные тесты. Самое главное, интегратору необходимо убедиться, что все компоненты, разработанные разными разработчиками, хорошо подходят и в конечном итоге программное обеспечение работает должным образом. Чтобы гарантировать, что у интегратора есть критерии приемлемости, и активно предотвращать то, что может пойти не так, важно автоматизировать эти критерии с помощью Continues integration .

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

3 Инструменты и автоматизация: Для создания независимой от человека системы полезны инструменты автоматизации, такие как Jenkins. На основе стратегии тестирования различные уровни тестирования могут быть выполнены с помощью средств автоматизации.