Один мой коллега сказал мне , что он думает , в создании нашего CI сервер , чтобы вернуться фиксаций , которые не строить, так что HEAD
в master
всегда устойчиво (как при прохождении сборки по крайней мере).
Это лучшая практика, или она может быть более проблематичной, чем просто master
сломаться, пока разработчик не исправит это?
Я думаю, что отмена коммита усложнит задачу чтения коммита и исправления (разработчик должен будет отменить восстановление, а затем зафиксировать исправление, что также загромождает git log
), и мы должны просто оставить коммит и затем зафиксировать фикс. Несмотря на то, что я вижу некоторые преимущества в master
стабильности, этот возврат неудачных коммитов не убеждает меня.
редактирование: не имеет значения, является ли это master
или любая другая ветвь разработки, но вопрос остается тем же: должна ли система CI вернуть коммит, который провалил сборку?
другое (длинное) редактирование: Хорошо, мы используем git
странным образом. Мы считаем, что концепция ветвей идет вразрез с реальным CI, потому что принятие ветки изолирует вас от других разработчиков и их изменений, а также добавляет время, когда вам нужно реинтегрировать свою ветку и справляться с возможными конфликтами. Если все фиксируют master
это, конфликты сводятся к минимуму, и каждый коммит проходит все тесты.
Конечно, это вынуждает вас нажимать только стабильную версию (или вы нарушаете сборку) и более тщательно программировать, чтобы не нарушать обратную совместимость и не переключать функции при внедрении новых функций.
Есть компромиссы при выполнении КИ тем или иным способом, но это выходит за рамки вопроса (см. Соответствующий вопрос для этого). Если вы предпочитаете, я могу перефразировать вопрос: небольшая команда разработчиков работает вместе в функциональной ветви. Если один разработчик фиксирует что-то, что нарушает сборку для этой ветви, должна ли система CI отменить фиксацию или нет?
источник
master
с самого начала. Для этого используются ветки разработки и функций. Затем эти изменения происходят в чем-то вроде ветки интеграции, где вы можете проверить, будут ли все новые функции нескольких разработчиков работать вместе, и только если они протестированы, они могут перейти в мастер. Или, по крайней мере, это один из возможных рабочих процессов.Ответы:
Я был бы против этого по следующим причинам:
Каждый раз, когда вы настраиваете автоматизированный инструмент для изменения кода от вашего имени , существует риск того, что он получит неправильный код или возникнет ситуация, когда вам потребуется отменить это изменение (например, последняя версия Google Mock). в нем была ошибка, так что это не ошибка вашего кода) и вам придется тратить время на ее перенастройку. Кроме того, всегда есть небольшой риск того, что сборка не удастся из-за ошибки в системе сборки, а не из-за ошибки в вашем коде. Для меня CI - это уверенность в правильности моего кода ; это просто превратило бы меня в еще один источник потенциальных проблем, о которых я мог бы беспокоиться.
Ошибки, нарушающие «сборку», должны быть глупыми ошибками, исправление которых занимает очень мало времени (как вы указали в комментарии, это верно для вас). Если на мастер регулярно попадают более тонкие и сложные ошибки, то правильное решение состоит не в том, чтобы «исправить это быстрее», а в том, чтобы быть более осторожным при просмотре ветвей функций, прежде чем они будут объединены.
Оставить мастера неустранимым на несколько минут, пока ошибка исправлена, никому не повредит. Не то чтобы генеральный директор лично проверял мастер и публиковал код прямо в любое время (хотя бы, надеюсь, без вашего участия). В маловероятном случае , что вам нужно , чтобы выпустить что - то прежде , чем вы можете исправить ошибку, то вы можете легко принять решение вновь обратиться вручную перед публикацией.
источник
Давайте сначала договоримся об условиях.
Лично я использую термины «Непрерывная сборка» и «Непрерывная интеграция», чтобы различать два разных сценария:
Последнее, Непрерывная интеграция, означает, что репозиторий, который он защищает, всегда зеленый 1 : он строго лучше.
Ваш вопрос действительно имеет смысл только для Continuous Build, поэтому я отвечу, если это ваша установка.
1 : Экологические причины также могут испортить сборку, например, тест с жестко запрограммированным годом (2015) может начать проваливаться. Январь 2016 года, диск может быть заполнен, ... И, конечно, существует проблема нестабильности тесты. Я надменно игнорирую эти проблемы здесь; иначе мы никогда никуда не доберемся.
Если у вас есть настройка Continuous Build, вы действительно можете автоматизировать аннулирование коммитов, которые могли нарушить сборку, однако есть несколько тонкостей.
Обратите внимание, что в этой системе, в случае нестабильного теста или совместной работы сотрудника, часто совершающего дерьмо, многие хорошие коммиты будут отменены. Тогда ваши сотрудники будут ненавидеть вас.
Надеюсь, что мой рассказ ужасов выявил проблемы с разрешением испорченного репозитория, и теперь вы реализуете правильный конвейер непрерывной интеграции, в котором PR никогда напрямую не помещаются в репозиторий, а вместо этого ставятся в очередь для объединения в рабочую очередь и интегрируются по одному ( или по свертке):
Попробовав оба, это строго лучше.
источник
master
к поврежденному коду доступен для извлечения, а затем исправить эту ситуацию, когда тесты не пройдут. Все остальные используют «пессимистичную» стратегию, как вы советуете, и делают доступным только код, доступный для извлечения.master
», что в идеале - это то, что разработчики могут делать волей-неволей, но для этого нужно отложить принятие коммитовmaster
до того, как они будут протестированы и пройдены. Если разработчик хочет Вишневый непроверенный или проверенный-и-неудачный код, это тоже хорошо, и код «доступен» в этом смысле, это просто не то, что я имею в виду)Это проблематично. Человек, решающий, что «главный HEAD сломан; я верну главное изменение», полностью отличается от системы CI, делающей то же самое.
Вот несколько недостатков:
Ошибки в процессе автоматического обращения испортят хранилище;
это предполагает, что один набор изменений (самый верхний) испортил сборку (что нереально)
Сопровождающие будут иметь больше работы для решения проблемы, чем просто расследование и фиксация (им также придется взглянуть на обратную историю)
Это убеждение (ветви против CI) неверно. Подумайте о том, чтобы сохранить одну стабильную ветвь, в которой вы фиксируете только тестовые наборы, проверенные модулем . Остальные (ветки функций и локальные ветки) должны нести ответственность за каждого разработчика, а не быть частью вашей политики CI.
В тематических ветках вы хотите быть изолированными от других разработчиков. Это позволяет вам:
выполнить поисковое кодирование
экспериментировать с кодовой базой
выполнять частичные коммиты (эффективно коммитить нерабочий код) для настройки точек резервного копирования (на случай, если вы испортите), для создания более значимой истории изменений (с помощью сообщений фиксации), а также для резервного копирования вашей работы и полного переключения на что-то другое ( время, которое требуется для написания "git commit && git checkout")
выполнять задачи с низким приоритетом, которые занимают много времени (например, вы хотите выполнить рефакторинг, который изменяет все 80 классов слоя данных: вы изменяете два в день, пока вы не измените все из них, пока код не скомпилируется (но вы можете сделать это без влияния на кого-либо, пока вы не можете сделать один коммит).
Это не должно За фиксацию стабильного кода в вашей ветви CI отвечает коммиттер, а не автоматизированная система.
источник
Я бы предложил использовать среду Gerrit + Jenkins, чтобы ваша ветка master всегда была в хорошей форме. Люди отправляют свой новый код в Gerrit, который запускает задание Jenkins для извлечения этого патча, сборки, тестирования и так далее. Если другим разработчикам понравился ваш патч и Jenkins успешно завершил свою работу, то Gerrit объединит этот фрагмент кода с вашей основной веткой.
Это похожая среда, описанная @ brian-vandenberg
Помимо поддержания вашей ветки в хорошем состоянии, вы также добавляете этап проверки кода, который улучшает качество кода и обмен знаниями о вашем программном обеспечении.
[1] Дженкинс https://jenkins-ci.org/
[2] Геррит https://www.gerritcodereview.com/
источник
CI никогда не должен изменять историю коммитов репо.
Правильным решением здесь является отсутствие коммитов, добавляемых в главную ветку, если они не были проверены и проверены.
Работаете ли вы над функциональными ветвями, автоматически ли запускается CI на них, и, если сборки терпят неудачу, не объединяйте их в master.
У вас может быть дополнительная сборка, которая тестирует слияния, если это вызывает озабоченность, запустив ветку компонентов и во время сборки слияния мастер / интеграция / что угодно в локальной ветке, а затем запустив тесты.
источник
Мы используем Jenkins для нашего сервера сборки и используем модель сторожевого устройства для отправки коммитов - где комбинация Jenkins и триггеров фиксации (которые гарантируют, что рецензенты выполнили свою работу) является сторожевым устройством.
Коммиты косвенно проталкиваются через завиток в Jenkins, где он клонирует мастер репо, затем извлекает коммит (ы) для объединения и выполняет все необходимые сборки (для Linux / solaris). Если все сборки завершены, коммит подталкивается.
Это позволяет избежать многих, если не всех проблем, которые обсуждались до сих пор:
Это также позволяет нам напрямую обеспечивать выполнение других требований, таких как успешное завершение модульных тестов.
источник
Сколько раз вы получали это автоматическое письмо, в котором говорилось, что ваш последний коммит нарушил сборку? Сколько раз это неправильно? Но теперь вам нужно проверить, действительно ли это был вы или кто-то еще, кто сделал еще один коммит в то же время. Или, может быть, это было что-то экологическое.
Если система не знает наверняка, то я, конечно, не хочу ее автоматизировать.
источник
Заданный вопрос ошибочен. Я уважаю это заявление, хотя
«Мы считаем, что концепция ветвей идет вразрез с реальным CI, потому что принятие ветки изолирует вас от других разработчиков и их изменений»
Что вы должны делать, хотя эти шаги
ПОТОМ то, что мы делаем, это ставим ловушку git commit для предотвращения того, чтобы КАЖДЫЙ из них действительно совершал мастеринг. Он отлично работает .... НИКАКИХ неработающих сборок и НИКАКИХ возвращающихся коммитов от мастера тоже.
позже, Дин
источник