вебмастер, фидошник
0,0
рейтинг
5 августа 2013 в 17:45

Разработка → GitHub Flow: рабочий процесс Гитхаба перевод

Краткое предисловие переводчика.
Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

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

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow


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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба


Итак, почему мы в Гитхабе не используем git-flow? Главная проблема в том, что у нас принято беспрестанное внедрение изменений. Рабочий процесс git-flow создавался в основном в помощь «выпускам» нового кода. А у нас нет «выпусков», потому что код поступает на продакшен (основной рабочий сервер) ежедневно — иногда по нескольку раз в день. Мы можем подавать для этого команды боту в той же чат-комнате, в которой отображаются итоги CI (интеграционного тестирования). Мы стремимся сделать процесс тестирования кода и его внедрения как можно проще, чтобы каждому сотруднику он был удобен в работе.

У такого частого внедрения новинок есть ряд достоинств. Если оно случается каждые несколько часов, то почти невозможно возникнуть большому количеству крупных багов. Небольшие недочёты случаются, но они могут быть исправлены (а исправления, в свою очередь, внедрены) очень быстро. Обычно пришлось бы делать «хотфикс» или как-то ещё отступать от нормального процесса, но для нас это становится просто частью нормального процесса: в рабочем процессе Гитхаба нет разницы между хотфиксом и небольшою фичею.

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

Как мы это делаем


Итак, каков рабочий процесс Гитхаба?

  • Содержимое ветви master всегда работоспособно (deployable).
     
  • Начиная работу над чем-то новым, ответвляйте от ветви master новую ветвь, имя которой соответствует её предназначению (например, «new-oauth2-scopes»).
     
  • Закоммитив в эту ветвь локально, отправляйте регулярно свою работу и в одноимённую ветвь на сервере.
     
  • Когда вам понадобится отзыв, или помощь, или когда вы сочтёте ветвь готовою ко слиянию, отправьте запрос на слияние.
     
  • После того, как кто-то другой просмотрел и одобрил фичу, вы можете слить вашу ветвь в ветвь master.
     
  • После того, как ветвь master пополнилась новым кодом, вы можете немедленно внедрить его на продакшен и вам следует сделать это.

Вот и весь рабочий процесс. Он очень прост и результативен, он работает для довольно крупных рабочих групп — в Гитхабе сейчас работает 35 человек, из которых, может быть, пятнадцать или двадцать одновременно работают над одним и тем же проектом (github.com). Думаю, что большинство команд разработчиков (групп, одновременно работающих с логикою одного и того же кода, что может порождать конфликты) имеют такой же размер — или меньше такого. Особенно группы, достаточно прогрессивные для того, чтобы заниматься быстрым и последовательным внедрением.

Итак, давайте по порядку рассмотрим каждый шаг.

Содержимое ветви master всегда работоспособно (deployable)


В общем-то это единственное жёсткое правило во всей системе. Есть только одна ветвь, имеющая всегда некоторое особенное значение, и её мы назвали master. Для нас это значит, что код этой ветви либо внедрён на продакшен, либо, в худшем случае, окажется внедрён в течение нескольких часов. Эта ветвь очень редко подвергается откручиванию на несколько коммитов назад (для отмены работы): если возникает проблема, то отменяются изменения из коммитов или совершенно новые коммиты исправляют проблему, но сама ветвь почти никогда назад не откручивается.

Ветвь master стабильна. Внедрение её кода на продакшен или создание новых ветвей на её основе — это всегда, всегда безопасно. Если от вас в master поступает неоттестированный код или он ломает сборку, то вы нарушили «общественный договор» команды разработчиков и у вас на душé должны кошки поскрести по этому поводу. Каждая ветвь подвергается у нас тестированию, а итоги поступают в чат-комнату — так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.

Ответвляйте от ветви master новые ветви, имена которых соответствуют предназначению


Когда хотите поработать над чем-то новым, ответвляйте от стабильной ветви master новую ветвь, имя которой соответствует предназначению. (Например, в коде Гитхаба прямо сейчас есть ветви «user-content-cache-key», «submodules-init-task», «redis2-transition».) Такое наименование имеет несколько достоинств. Например, достаточно подать команду fetch, чтобы увидеть, над какими темами работают остальные. Кроме того, оставив ветвь на какое-то время и возвратившись к ней позднее, по имени проще припомнить, о чём она была.

И это приятно, потому что, когда на Гитхабе заходим на страницу со списком ветвей, то легко видеть, над какими ветвями недавно поработали (и, приблизительно, каков был объём работы).

[скриншот]

Это почти как список будущих фич с грубою оценкою нынешнего состояния их. Если не пользуетесь этой страницею, то знайте — у ней классные возможности: она вам показывает только те ветви, в которых была проделана работа, уникальная по отношению к выбранной вами в настоящий момент ветви, да ещё и сортирует таким способом, чтобы ветви с наиболее недавнею работою были сверху. Если захочется полюбопытствовать, то я могу нажать на кнопку «Compare» и поглядеть на точный объединённый diff и на список коммитов, уникальных для этой ветви.

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

Постоянно отправляйте код именованных ветвей на сервер


Другое крупное отличие от git-flow: мы беспрерывно делаем push ветвей на сервер. С точки зрения внедрения приходится по-настоящему беспокоиться только о ветви master, так что push никого не озадачит и ничего не поломает: всё, что не master это просто код, над которым идёт работа.

Этим создаётся страховочная копия на случай утраты ноутбука или выхода жёсткого диска из строя. Этим поддерживается, что ещё важнее, постоянный обмен сведениями между разработчиками. Простой командою «git fetch» можно получить список тех TODO, над которыми все сейчас работают.

$ git fetch
remote: Counting objects: 3032, done.
remote: Compressing objects: 100% (947/947), done.
remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (1993/1993), completed with 213 local objects.
From github.com:github/github
 * [new branch]      charlock-linguist -> origin/charlock-linguist
 * [new branch]      enterprise-non-config -> origin/enterprise-non-config
 * [new branch]      fi-signup  -> origin/fi-signup
   2647a42..4d6d2c2  git-http-server -> origin/git-http-server
 * [new branch]      knyle-style-commits -> origin/knyle-style-commits
   157d2b0..d33e00d  master     -> origin/master
 * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
   ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
 * [new branch]      svg-tests  -> origin/svg-tests
   87bb870..9da23f3  view-modes -> origin/view-modes
 * [new branch]      wild-renaming -> origin/wild-renaming

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

В любое время создавайте запрос на слияние


GitHub снабжён поразительною системою обзора кода, которая называется запросами на слияние; боюсь, недостаточно разработчиков вполне знают о ней. Многие пользуются ею в обыкновенной работе над открытым исходным кодом: форкнул проект, обновил код, отправил запрос на слияние к хозяину проекта. Однако эта система также может употребляться как средство внутрикорпоративной проверки кода, и так её используем мы.

Её мы, собственно, скорее используем как средство просмотра и обсуждения ветвей, чем как запрос на слияние. GitHub поддерживает отсылку запроса на слияние из одной ветви в другую в одном и том же проекте (открытом или приватном), так что в запросе можно сказать «мне нужна подсказка или обзор этого кода», а не только «прошу принять этот код».

[скриншот]

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

[скриншот]

Можно, наконец, видеть и то, что код находится ещё на стадии испытаний: это ещё не ветвь, подготовленная ко внедрению, мы используем запросы на слияние для рассмотрения кода задолго до того, как захотим действительно слить его в master и отправить на внедрение.

Если ваша работа над фичею или ветвью застревает и нужна помощь или совет, или если вы — разработчик, а на вашу работу надо бы посмотреть и дизайнеру (или наоборот), или даже если кода у вас мало (или вовсе нет), но есть какая-то композиция скриншотов и общих идей, то вы открываете запрос на слияние. Система Гитхаба позволяет добавлять людей к обсуждению @-упоминанием их, так что если обзор или отклик нужен от конкретного человека, то можно в запросе упомянуть его (вы видели выше, как Джош сделал это).

И это круто, потому что в запросах на слияние можно комментировать отдельные строки объединённого диффа, или отдельные коммиты, или весь запрос в целом — и копии реплик сложатся в единое обсуждение. Также можно продолжать пополнение ветви кодом, так что если кто-нибудь укажет на ошибку или на позабытую возможность в коде, то можно поместить исправление в ту же ветвь, и GitHub покажет новые коммиты в обсуждении, так что и вот так можно трудиться над ветвью.

Если ветвь существует слишком долго и вы ощущаете, что код в ней рассогласовывается с кодом ветви master, то можно код из master влить в вашу ветвь и продолжить работу. В обсуждении запроса на слияние или в списке коммитов без труда видно, когда ветвь последний раз обновляли кодом, взятым из master.

[скриншот]

Когда работа над ветвью целиком и полностью окончена и вы ощущаете её готовою ко внедрению, тогда можете переходить к следующему шагу.

Слияние только после обзора запроса


Мы не работаем непосредственно в ветви master, но и работу из именованной ветви мы не подвергаем слиянию сразу после того, как сочтём её оконченною — сперва мы стараемся получить одобрение от других сотрудников компании. Оно обычно имеет форму «+1», или эмоджи, или комментария «:shipit:», но кого-то ещё нам надо привести поглядеть на ветвь.

[скриншот]

Когда одобрение получено, и ветвь прошла CI, мы можем слить её в master и на внедрение; в этот момент запрос на слияние будет закрыт автоматически.

Внедрение непосредственно после обзора


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

Наш campfire-бот, по имени hubot, может внедрять код по указанию от любого из сотрудников. Достаточно подать в чате команду hubot deploy github to production, и код поступит на продакшен, где начнётся перезапуск (с нулевым даунтаймом) всех необходимых процессов. Можете сами судить о том, как часто это случается на Гитхабе:

[скриншот]

Как видите, шесть разных человек (среди которых один саппорт и один дизайнер) внедряли код более двух дюжин раз за сутки.

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

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

Заключение


Git сам по себе довольно сложен для понимания. Если его ещё и употреблять в рабочем процессе более сложном, чем это необходимо, то дело кончится ежедневным чрезмерным усилием рассудка. Я всегда буду отстаивать употребление простейшей из возможных систем, пригодных для работы вашей группы, и до тех пор, пока система эта не перестанет работать; только тогда добавляйте сложность, когда никак не удаётся избежать этого.

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

Для групп, труд которых строится вокруг доставки кода, которые ежедневно обновляют продакшен, беспрерывно тестируют и внедряют фичи, я рекомендовал бы более простой рабочий процесс — такой, как GitHub Flow.
Перевод: Scott Chacon
Mithgol the Webmaster @Mithgol
карма
60,5
рейтинг 0,0
вебмастер, фидошник
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (47)

  • +3
    Ну, в целом как-то так большинство команд, в которых мне довелось работать, и используют Git. Разве что с немного меньшей степенью автоматизации. Канонический процесс git-flow, ИМХО, излишне тяжел для проектов стандартного и даже довольно большого размера (ведь Github маленьким точно не назовешь), да и правило «деплой как минимум раз в сутки» лично мне импонирует.
    • +2
      «Меньшею», а не «меньшей» — автор может не понять…
    • +10
      А мне, честно говоря, из всего вышеизложенного более всего импонирует знание о том, что команда Гитхаба отложила в сторону такой инструмент, как rebase. Напрочь отложила.

      То есть у них методика в стиле «master обогнал нашу ветку — вливаем в ветку код мастера и поехали дальше», а не в стиле «master обогнал нашу ветку — судорожно пытаемся натянуть все N коммитов на новую голову его».

      Вот подлинно люди, заботящиеся о ненапряжении нервов и рассудка разработчиков и об экономии усилий их!
      • 0
        Ну, я лично от использования rebase никакого особого дискомфорта не испытывал. Зато чистая и прозрачная история без технических коммитов мне нравится, так что периодически даже балуюсь ключиком -i, чтобы, например, переставить коммит с фиксом поближе к тому месту, где баг появился.
        • 0
          А это потому что у каждого свой вкус.

          Я-то и вот такого коммита не погнушаюсь.
          • +2
            На мой взгляд, абсолютно правильный коммит. В коммит следует выделять минимально возможное осмысленное изменение. Заодно и каждое изменение отдельно описывается в сообщении к коммиту.

            Бывает, в одном коммите с элегантным названием «a batch of small improvements and bug fixes» можно увидеть много не связанных между собой изменений без отдельного описания каждого из них. А потом находишь, что баг возник в таком коммите и не знаешь, где именно.

            А вот rebase, если изменения не мешают друг другу, не повредит, чтобы историю было проще читать.
          • +3
            Название коммита очень говорящее. Пришлось список коммитов смотреть чтобы его обнаружить :)
          • 0

            То есть во всём остальном код настолько идеален, что единственное, чего можно в нём улучшить, — это развесить ёлочные игрушки на концы веток кода?

  • 0
    Удивляет остуствие тестирования(не юнит).
    • +1
      >> Каждая ветвь подвергается у нас тестированию, а итоги поступают в чат-комнату — так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.
      • 0
        Ничто не мешает написать тест говорящий ОК с ошибкой. Имеется в виду тестирование тестировщиками.
        • +1
          Ну, я бы не стал говорить об отсутствии ручного тестирования, как такового. Нельзя просто так взять и запушить новый код в master, сперва его нужно «обсудить» с товарищами по команде. Это обсуждение вполне может включать тестирование. Скорее речь идёт об отсутствии именно отдела с тестеровщиками, которые основательно тестируют каждую сборку, прежде чем та попадёт в мастер. Я полагаю, что у разработчиков гитхаба хватает компетенции, чтобы совместными усилиями самостоятельно протестировать изменения.
    • +1
      я полагаю, что дженкинс гоняет и интеграционные тесты
      а отсутствие «ручного» тестирование — это обязательный аттрибут сколько-н развитой группы разработки
      • +1
        Не думаю, что так уж и «отсутствие». Просто относительно малый сегмент. Все таки полезно иногда и руками все опробовать бывает =)
    • 0
      Пользователи тестируют. А они реагируют постфактум, как-то так: twitter.com/githubstatus
  • –2
    Плохой перевод какой-то:(
    • +2
      Так читайте оригинал =) Я, например, в принципе технические статьи на русском тяжко воспринимаю, поэтому сразу отмотал к ссылке на исходный пост.
      • –1
        так я и прочитал, но зачем здесь перевод тогда?
        • +13
          Ой, как я не люблю вот это вот патетическое: «Зачем постить это на Хабре?» =) Во-первых, наличие перевода лучше, чем его отсутствие. Во-вторых, я знаю немало программистов, которые на любую англоязычную ссылку попросят перевод, и только в том случае, если перевода не существует, вздохнут и пойдут читать оригинал. В-третьих, наличие поста на Хабре дает возможность обсудить сабж, чем мы тут все и занимаемся.
    • +5
      Читая статью приходится переводить с мизгольного на русский =)
      • +3
        Шутку юмора оценил, плюсанул. Но согласитесь, он, в отличие от многих, почти не делает ошибок в тексте.
        Я только за это готов «терпеть» его язык :)
      • +3
        не троньте мизгольный! Я к середине статьи уже твердо подозревал, кто автор перевода — и приятно не ошибся.
        • +3
          Сложночитаемые окончания на «ю» с первого раза безошибочно указывают на Мицгола :-)
  • 0
    От git-flow отказались, потому что не смогли вписать в процесс пул реквесты, и, соответственно, ревью кода… Так что как-то так и используем.
    • 0
      Разве нельзя делать пул реквесты в ветку feature или develop?
      • +1
        Я в подробностях не помню, но при вливании фичи в девелоп по git-flow во первых автоматически фича-бранч удаляется, а во вторых еще что-то происходит. То есть не так, если нажать «merge» на гитхабе. А делать пул реквест только ради код-ревью и потом его закрывать — ну это костыль какой-то.
        • 0
          Не при вливании фичи, а при завершении — никто не заставляет делать flow feature finish — можно просто сделать мерж.
          • +1
            Окей, но git-flow тем и должен быть удобен — feature start, feature finish, etc. Если мне нужно мерджить бранчи на гитхабе, потом удалять удаленный и локальный бранчи — зачем мне git-flow? Я именно про инстумент, а не про концепцию. Она то нормальная.
  • 0
    git flow удобен когда у вас скажем так не «сайт»
    описанная здесь работа это в терминологии git-flow работа с ветками feature и develop
    просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.

    А git-flow — действительно удобный скрипт, если не напрягает тот факт что ветки по умолчанию называются по другому, то почему бы и нет, хотя это хороший аддон к скрипту — по сути rolling модуль.
    • +1
      просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.

      Разве обязательно есть? Очень часто встречается ныне поддержка в виде только «обновите версию».
  • –3
    • +3
      Это и есть git-flow. В смысле, автор git-flow и автор этого поста — одно и то же лицо.
  • +1
    То ли что-то не договаривается, то ли я что-то не понимаю. На каждый ветку, еще не влитую в мастер поднимаются отдельные дев- и тест- (для внутренних и внешних тестеров) сервера как-то? Как? автоматом или ручками? Или тестирование перед выкладыванием в продакшен ограничивается ревьюированием кода и автотестами? Ну и если дев сервер ещё как-то можно поднять локально или независимо от гита заливать на него код, то с тестом, на котором тестеры должны «кнопочки понажимать» перед тем как дать окончательной согласие на продакшен, как быть?

    В общем как-то не получается у меня простая и понятная схема, когда есть два общих сервера (продакшен и тест) и у каждого разработчика дев-сервер, доступный остальным (то есть он не локальным должен быть). С дев ладно — можно прямо в /var/www/<dev-name> на сервере работать по ssh или примонтировав по sshfs, держа её под контролем git. А вот как с тестовым быть? Деплоить его с мастера, а после приемки деплоить на продакшен? Тогда, получается нельзя вливать фичи в мастер пока тестирование идет. Ответвить тест от мастера? Похожая проблема. Фиксировать версию на тесте и деплоить продакшен с мастера не с головы, а с этой версии? Ограничения на разработчиков — не могут в любой момент залить на тест, пока там тестируется что-то другое.

    Кто как выходит?
    • +1
      Автоматизированный CI.
    • +4
      Чуть более развернутый вариант ответа «Автоматизированный CI»:
      автор упоминает что у них Дженкинс запускает все тесты, значит для каждой ветки Дженкинсом автоматически создается/обновляется новая инстанция приложения (веб-сайта), на которой запускается набор каких-нибудь Селениум + J(php)unit тестов.
      Вполне себе стандартный подход, ну а то что сразу руками специально обученные тестеры не тестируют — судя по тому что написано что правила у них не жесткие, то крупные изменения — тестируют, а мелкие — уже в продакшне вместе с пользователями ;)

      Хорошо настроенный и прокачаный Дженкинс — вполне справляется с автоматизацией и поднятия копий приложения (деплоя) и тестирования, и общения с гитом и багтрекером.
    • +2
      Я думаю, что имеется в виду именно CI + ревью кода + ручное тестирование одного из разработчиков (или нескольких). Разработчик делает git fetch + git checkout <нужная ветка> и проверяет изменения, сделанные в пулл реквесте на баги. Ну а для простых веток достаточно ревью кода, по тестам видно покроют они или нет функционал из пулл реквеста, а CI скажет прошли ли сами тесты.
      • 0
        Для дев-сервера или внутреннего тестирования (по инициативе тестировшика) git fetch + git checkout подходит более-менее. Но вот как только начинается внешнее тестирование, то начинаются организационные проблемы. Коммит с фичей или фиксом прошел внутренне тестирование, все изменения с master (то есть продакшена) влиты. И таких коммитов, ожидающих внешнего тестирования (в удобное для внешнего тестировщика время) несколько. Вливать их в master нарушает принцип «в master должен быть production код». Давать на тестирование каждую фиче/фикс ветку отдельно не разумно из-за малой оперативности взаимодействия с внешним тестировщиком (заказчиком). Видится как-то как создание ветки test от master куда вливаются все коммиты, прошедшие локальное тестирование на конкретную подзадачу, и заказчику передается «дифф» (на человеческом языке) отличий (список как бы выполненных подзадач) от текущего продакшена (или прошлого теста?), но непонятно как быть если часть коммитов заказчик принял, одобрил их размещение на продакшене, и, мало того, требует срочного размещения, а часть нет и переделка займёт долгое время.
        • +1
          Скорее всего, раз задача описана грамотно и создана с участием заказчика, то не может такого быть, чтобы заказчик сказал — «Этого не должно быть в продакшене и точка!». Заказчик может найти баг, но переделывать целиком он вряд ли заставит. А код ревью и проверка другим разработчиком должны уменьшить риск. Ну и иногда можно сделать revert. Так что думаю, что это осознанно принятый риск для ускорения процесса разработки.
          • +1
            не может такого быть

            может :(
    • +1
      Возможно, Вы найдете ответ здесь: Continuous Deployment at Github

      Все, кому интересен GitHub workflow, могут почитать ответы и задать вопросы тут: holman/feedback/issues
  • –14
    И где ссылка на оригинальный пост? За кого автор перевода принимает своих читателей?
    • +11
      Она всегда тут для переводов:
      image
      • –10
        Спасибо.
        Это недоработка интерфейса хабра. Большинство переводчиков её обходят, давая ссылку в начале или в конце поста.
      • 0
        Юзерскрипт HabrAjax дублирует её сверху:
    • +4
      Как-то слишком грубо, особенно с учетом того, что у вас нет не одного топика и даже дельной мысли в комментариях
  • 0
    А мне вполне себе нравится git-flow. В случае работы по эджайлу с итеративными выгрузками существование develop-ветки вполне себя оправдывает.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.