Комментарии 47
Ну, в целом как-то так большинство команд, в которых мне довелось работать, и используют Git. Разве что с немного меньшей степенью автоматизации. Канонический процесс git-flow, ИМХО, излишне тяжел для проектов стандартного и даже довольно большого размера (ведь Github маленьким точно не назовешь), да и правило «деплой как минимум раз в сутки» лично мне импонирует.
«Меньшею», а не «меньшей» — автор может не понять…
А мне, честно говоря, из всего вышеизложенного более всего импонирует знание о том, что команда Гитхаба отложила в сторону такой инструмент, как rebase. Напрочь отложила.
То есть у них методика в стиле «master обогнал нашу ветку — вливаем в ветку код мастера и поехали дальше», а не в стиле «master обогнал нашу ветку — судорожно пытаемся натянуть все N коммитов на новую голову его».
Вот подлинно люди, заботящиеся о ненапряжении нервов и рассудка разработчиков и об экономии усилий их!
То есть у них методика в стиле «master обогнал нашу ветку — вливаем в ветку код мастера и поехали дальше», а не в стиле «master обогнал нашу ветку — судорожно пытаемся натянуть все N коммитов на новую голову его».
Вот подлинно люди, заботящиеся о ненапряжении нервов и рассудка разработчиков и об экономии усилий их!
Ну, я лично от использования rebase никакого особого дискомфорта не испытывал. Зато чистая и прозрачная история без технических коммитов мне нравится, так что периодически даже балуюсь ключиком -i, чтобы, например, переставить коммит с фиксом поближе к тому месту, где баг появился.
На мой взгляд, абсолютно правильный коммит. В коммит следует выделять минимально возможное осмысленное изменение. Заодно и каждое изменение отдельно описывается в сообщении к коммиту.
Бывает, в одном коммите с элегантным названием «a batch of small improvements and bug fixes» можно увидеть много не связанных между собой изменений без отдельного описания каждого из них. А потом находишь, что баг возник в таком коммите и не знаешь, где именно.
А вот rebase, если изменения не мешают друг другу, не повредит, чтобы историю было проще читать.
Бывает, в одном коммите с элегантным названием «a batch of small improvements and bug fixes» можно увидеть много не связанных между собой изменений без отдельного описания каждого из них. А потом находишь, что баг возник в таком коммите и не знаешь, где именно.
А вот rebase, если изменения не мешают друг другу, не повредит, чтобы историю было проще читать.
Название коммита очень говорящее. Пришлось список коммитов смотреть чтобы его обнаружить :)
То есть во всём остальном код настолько идеален, что единственное, чего можно в нём улучшить, — это развесить ёлочные игрушки на концы веток кода?
Удивляет остуствие тестирования(не юнит).
>> Каждая ветвь подвергается у нас тестированию, а итоги поступают в чат-комнату — так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.
Ничто не мешает написать тест говорящий ОК с ошибкой. Имеется в виду тестирование тестировщиками.
Ну, я бы не стал говорить об отсутствии ручного тестирования, как такового. Нельзя просто так взять и запушить новый код в master, сперва его нужно «обсудить» с товарищами по команде. Это обсуждение вполне может включать тестирование. Скорее речь идёт об отсутствии именно отдела с тестеровщиками, которые основательно тестируют каждую сборку, прежде чем та попадёт в мастер. Я полагаю, что у разработчиков гитхаба хватает компетенции, чтобы совместными усилиями самостоятельно протестировать изменения.
я полагаю, что дженкинс гоняет и интеграционные тесты
а отсутствие «ручного» тестирование — это обязательный аттрибут сколько-н развитой группы разработки
а отсутствие «ручного» тестирование — это обязательный аттрибут сколько-н развитой группы разработки
Пользователи тестируют. А они реагируют постфактум, как-то так: twitter.com/githubstatus
Плохой перевод какой-то:(
Так читайте оригинал =) Я, например, в принципе технические статьи на русском тяжко воспринимаю, поэтому сразу отмотал к ссылке на исходный пост.
так я и прочитал, но зачем здесь перевод тогда?
Ой, как я не люблю вот это вот патетическое: «Зачем постить это на Хабре?» =) Во-первых, наличие перевода лучше, чем его отсутствие. Во-вторых, я знаю немало программистов, которые на любую англоязычную ссылку попросят перевод, и только в том случае, если перевода не существует, вздохнут и пойдут читать оригинал. В-третьих, наличие поста на Хабре дает возможность обсудить сабж, чем мы тут все и занимаемся.
Читая статью приходится переводить с мизгольного на русский =)
От git-flow отказались, потому что не смогли вписать в процесс пул реквесты, и, соответственно, ревью кода… Так что как-то так и используем.
Разве нельзя делать пул реквесты в ветку feature или develop?
Я в подробностях не помню, но при вливании фичи в девелоп по git-flow во первых автоматически фича-бранч удаляется, а во вторых еще что-то происходит. То есть не так, если нажать «merge» на гитхабе. А делать пул реквест только ради код-ревью и потом его закрывать — ну это костыль какой-то.
git flow удобен когда у вас скажем так не «сайт»
описанная здесь работа это в терминологии git-flow работа с ветками feature и develop
просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.
А git-flow — действительно удобный скрипт, если не напрягает тот факт что ветки по умолчанию называются по другому, то почему бы и нет, хотя это хороший аддон к скрипту — по сути rolling модуль.
описанная здесь работа это в терминологии git-flow работа с ветками feature и develop
просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.
А git-flow — действительно удобный скрипт, если не напрягает тот факт что ветки по умолчанию называются по другому, то почему бы и нет, хотя это хороший аддон к скрипту — по сути rolling модуль.
То ли что-то не договаривается, то ли я что-то не понимаю. На каждый ветку, еще не влитую в мастер поднимаются отдельные дев- и тест- (для внутренних и внешних тестеров) сервера как-то? Как? автоматом или ручками? Или тестирование перед выкладыванием в продакшен ограничивается ревьюированием кода и автотестами? Ну и если дев сервер ещё как-то можно поднять локально или независимо от гита заливать на него код, то с тестом, на котором тестеры должны «кнопочки понажимать» перед тем как дать окончательной согласие на продакшен, как быть?
В общем как-то не получается у меня простая и понятная схема, когда есть два общих сервера (продакшен и тест) и у каждого разработчика дев-сервер, доступный остальным (то есть он не локальным должен быть). С дев ладно — можно прямо в /var/www/<dev-name> на сервере работать по ssh или примонтировав по sshfs, держа её под контролем git. А вот как с тестовым быть? Деплоить его с мастера, а после приемки деплоить на продакшен? Тогда, получается нельзя вливать фичи в мастер пока тестирование идет. Ответвить тест от мастера? Похожая проблема. Фиксировать версию на тесте и деплоить продакшен с мастера не с головы, а с этой версии? Ограничения на разработчиков — не могут в любой момент залить на тест, пока там тестируется что-то другое.
Кто как выходит?
В общем как-то не получается у меня простая и понятная схема, когда есть два общих сервера (продакшен и тест) и у каждого разработчика дев-сервер, доступный остальным (то есть он не локальным должен быть). С дев ладно — можно прямо в /var/www/<dev-name> на сервере работать по ssh или примонтировав по sshfs, держа её под контролем git. А вот как с тестовым быть? Деплоить его с мастера, а после приемки деплоить на продакшен? Тогда, получается нельзя вливать фичи в мастер пока тестирование идет. Ответвить тест от мастера? Похожая проблема. Фиксировать версию на тесте и деплоить продакшен с мастера не с головы, а с этой версии? Ограничения на разработчиков — не могут в любой момент залить на тест, пока там тестируется что-то другое.
Кто как выходит?
Автоматизированный CI.
Чуть более развернутый вариант ответа «Автоматизированный CI»:
автор упоминает что у них Дженкинс запускает все тесты, значит для каждой ветки Дженкинсом автоматически создается/обновляется новая инстанция приложения (веб-сайта), на которой запускается набор каких-нибудь Селениум + J(php)unit тестов.
Вполне себе стандартный подход, ну а то что сразу руками специально обученные тестеры не тестируют — судя по тому что написано что правила у них не жесткие, то крупные изменения — тестируют, а мелкие — уже в продакшне вместе с пользователями ;)
Хорошо настроенный и прокачаный Дженкинс — вполне справляется с автоматизацией и поднятия копий приложения (деплоя) и тестирования, и общения с гитом и багтрекером.
автор упоминает что у них Дженкинс запускает все тесты, значит для каждой ветки Дженкинсом автоматически создается/обновляется новая инстанция приложения (веб-сайта), на которой запускается набор каких-нибудь Селениум + J(php)unit тестов.
Вполне себе стандартный подход, ну а то что сразу руками специально обученные тестеры не тестируют — судя по тому что написано что правила у них не жесткие, то крупные изменения — тестируют, а мелкие — уже в продакшне вместе с пользователями ;)
Хорошо настроенный и прокачаный Дженкинс — вполне справляется с автоматизацией и поднятия копий приложения (деплоя) и тестирования, и общения с гитом и багтрекером.
Я думаю, что имеется в виду именно CI + ревью кода + ручное тестирование одного из разработчиков (или нескольких). Разработчик делает git fetch + git checkout <нужная ветка> и проверяет изменения, сделанные в пулл реквесте на баги. Ну а для простых веток достаточно ревью кода, по тестам видно покроют они или нет функционал из пулл реквеста, а CI скажет прошли ли сами тесты.
Для дев-сервера или внутреннего тестирования (по инициативе тестировшика)
git fetch + git checkout подходит более-менее. Но вот как только начинается внешнее тестирование, то начинаются организационные проблемы. Коммит с фичей или фиксом прошел внутренне тестирование, все изменения с master (то есть продакшена) влиты. И таких коммитов, ожидающих внешнего тестирования (в удобное для внешнего тестировщика время) несколько. Вливать их в master нарушает принцип «в master должен быть production код». Давать на тестирование каждую фиче/фикс ветку отдельно не разумно из-за малой оперативности взаимодействия с внешним тестировщиком (заказчиком). Видится как-то как создание ветки test от master куда вливаются все коммиты, прошедшие локальное тестирование на конкретную подзадачу, и заказчику передается «дифф» (на человеческом языке) отличий (список как бы выполненных подзадач) от текущего продакшена (или прошлого теста?), но непонятно как быть если часть коммитов заказчик принял, одобрил их размещение на продакшене, и, мало того, требует срочного размещения, а часть нет и переделка займёт долгое время. Скорее всего, раз задача описана грамотно и создана с участием заказчика, то не может такого быть, чтобы заказчик сказал — «Этого не должно быть в продакшене и точка!». Заказчик может найти баг, но переделывать целиком он вряд ли заставит. А код ревью и проверка другим разработчиком должны уменьшить риск. Ну и иногда можно сделать revert. Так что думаю, что это осознанно принятый риск для ускорения процесса разработки.
Возможно, Вы найдете ответ здесь: Continuous Deployment at Github
Все, кому интересен GitHub workflow, могут почитать ответы и задать вопросы тут: holman/feedback/issues
Все, кому интересен GitHub workflow, могут почитать ответы и задать вопросы тут: holman/feedback/issues
И где ссылка на оригинальный пост? За кого автор перевода принимает своих читателей?
А мне вполне себе нравится git-flow. В случае работы по эджайлу с итеративными выгрузками существование develop-ветки вполне себя оправдывает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GitHub Flow: рабочий процесс Гитхаба