Комментарии 19
Чего только не придумают, лишь бы DVCS не использовать.
Процесс Pre-Tested Commit никак не завязан на типе VCS.
Ух минусов-то насовали. А объяснить?
Поясню свою позицию. Pre-Tesred Commi суть костыль на случай, когда коммитить по какой-то причине нельзя, а результат интеграции узнать хочется. «Какая-то причина» в случае с CVCS — сама система контроля версий,
Я в Jenkins'е не волоку, но тот же Bamboo, например, умеет использовать Build Plan «родительской» ветки для веток «дочерних». Это позволяет каждому разработчику разносить свою ветку (или форк) вдребезги и пополам, запускать билды для _конкретных_ ревизий (а не для непонятно чего в виде патча) и не тревожить mainline.
С форками в CVCS мы все знаем, как обстоит. С бранчами несколько лучше, но тоже не сахар. Посему таковой функционал — лучшее, что можно предложить в случае с CVCS.
Поясню свою позицию. Pre-Tesred Commi суть костыль на случай, когда коммитить по какой-то причине нельзя, а результат интеграции узнать хочется. «Какая-то причина» в случае с CVCS — сама система контроля версий,
Я в Jenkins'е не волоку, но тот же Bamboo, например, умеет использовать Build Plan «родительской» ветки для веток «дочерних». Это позволяет каждому разработчику разносить свою ветку (или форк) вдребезги и пополам, запускать билды для _конкретных_ ревизий (а не для непонятно чего в виде патча) и не тревожить mainline.
С форками в CVCS мы все знаем, как обстоит. С бранчами несколько лучше, но тоже не сахар. Посему таковой функционал — лучшее, что можно предложить в случае с CVCS.
Почему? Я даже спрошу — а зачем он нужен вообще? Почему нельзя коммитить в отдельный бранч и проверять его?
Например, чтобы уменьшить число коммитов-фиксов по результатам прохождения интеграционных тестов. Да и вообще держать постоянно любой билд в статусе успешной сборки — хорошая практика.
Зачем уменьшать число коммитов? Что это дает? Если всегда работать над фичей в отдельном бранче, то количество коммитов не важно. Держать в статусе успешной — ну не знаю, для этого Jenkins и придуман, чтобы автоматически тестировать билд. В принципе, это задача девелопера перед коммитом прогнать все тесты локально. Ну или закоммитить в бранч и работать над другой задачей, пока Jenkins оттестирует все.
Ну, это — ваше решение (ваших лидов). Делать стабильные законченные коммиты или коммиты, которые рушат половину интеграционных тестов + за ним коммитить пачку фиксов.
НЛО прилетело и опубликовало эту надпись здесь
При мерже они все перейдут в продакшен ветку, если не предпринимать специальных мер.
Мне даже интересно стало увидеть ход ваших мыслей. Как вы завязываете одно на другом.
upd: я буду обновлять комментарии, перед отправкой своих. Спасибо, ответ получил.
upd: я буду обновлять комментарии, перед отправкой своих. Спасибо, ответ получил.
все понимаю, уважаю, но
просто ужасно.
настраиваем конкретную джобу
просто ужасно.
Leerooooy Jenkins! Извините.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Тестирование кода перед коммитом с помощью Jenkins и IDE от Jetbrains (IDEA, PhpStorm...)