Недельный цикл релизов: как сделать это возможным?

В моей компании (3-летний стартап веб-индустрии) у нас часто возникают проблемы с командой разработчиков, которая говорит: «А-а-а, это кризис, исправьте это сейчас!» (не все?)

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

Есть 13 разработчиков и 6 локальных / 9 оффшорных тестеров; Теория состоит в том, что только 4 разработчика (и все тестировщики) будут работать над выпусками с четными номерами, если только не придет кусок работы, который действительно требует определенного опыта от одного из других разработчиков. Каждый цикл будет содержать два дня работы разработчика и два дня работы по обеспечению качества (плюс один день определения объема работ / сортировки / ...).

Мои вопросы:

а) Есть ли у кого-нибудь опыт работы с этой длительностью цикла выпуска?

(б) Кто-нибудь слышал об этой длительности цикла выпуска, даже когда пытались?

(в) Если (а) или (б), как на Земле вы заставляете это работать? (Любые ошибки, которых следует избегать и т. Д., Также приветствуются.)

(d) Как мы можем минимизировать ущерб, если это усилие потерпит неудачу?

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

Главное, чтобы ваш сайт был полностью защищен автоматическими тестами - как модульными, так и сквозными приемочными тестами / спецификациями исполняемых файлов. Подразумевается, что это также означает, что ваша сборка полностью автоматизирована. На уровне приемлемости мы используем Robot Framework, который отлично подходит для быстрого создания поддерживаемого набора тестов благодаря подходу на основе ключевых слов. Для внешнего вида наш локальный тестер делает несколько кратких проверок, но у нас также есть пара ребят в Индии, которые проводят более тщательную проверку в разных браузерах (есть сайты, которые помогают с такими вещами, делая скриншоты для вас, например BrowserLab ).

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

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

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

Если вы постоянно находитесь в режиме «выхода из кризиса», я бы сказал, что было бы разумнее сделать шаг назад и пересмотреть ваш код и процесс. Очевидно, что есть какая-то неудача, которая постоянно повторяется.

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

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

Помните, что если вы постоянно спешите вносить изменения, вы с большей вероятностью допускаете ошибки в этих изменениях и ломаете что-то еще, пока делаете это.

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

Есть компания, которая выпускает 50 раз в день. Этот блог описывает, как они это делают .

Руководство потратило некоторое время на размышления о том, как уменьшить частоту этих «кризисных рабочих мест», и нашло решение, которое мы будем выпускать каждую неделю.

Похоже, ваше руководство чемпионы мира ... почему бы не инвестировать в ваш командный дух? Вы увидите, что проблемы исчезнут сами собой.

(a) + (b) ИМХО, согласно размеру вашей команды, это должно быть максимум две недели. Одна неделя будет работать для шоу одного человека или очень маленьких команд (например, 2 или 3).

(c) + (d) Но независимо от размера вашей команды или проекта, одним из первых, что я делаю, является автоматизация сборки и развертывания. Я экономлю дни, если не недели работы, делая это в первые дни проекта.

Ваши развертывания должны быть сделаны одним щелчком мыши. От источника к постановке, затем от постановки к производству. Есть много инструментов, чтобы сделать это возможным. От муравья / нанта до сверхтяжелых вещей, таких как Automated Build Studio .

Все может быть автоматизировано от развертывания файлов до обновления базы данных, включая резервные копии, уведомления, отчеты, ...