Поради щодо досягнення "постійної" доставки


14

Команда відчуває труднощі часто випускати програмне забезпечення (раз на тиждень). Далі йде типова хронологія випуску:

Під час ітерації:

  • Розробники працюють над історіями щодо відставання на короткотривалих (це з захопленням виконується) функціональних галузях, заснованих на головній галузі.
  • Розробники часто перетягують свої функції в гілку інтеграції, яка постійно будується і перевіряється (наскільки це стосується тестового покриття) автоматично.
  • Тестери мають можливість автоматичної розгортання інтеграції до режиму постановки, і це відбувається кілька разів на тиждень, що дозволяє постійно працювати з тестовими наборами.

Кожного понеділка:

  • проходить нарада з планування випуску, щоб визначити, які історії є «добре відомими» (на основі роботи тестувальників), а значить, буде у випуску. Якщо є відома проблема з історією, вихідна гілка витягується з інтеграції.
  • жодного нового коду (лише виправлення помилок, які запитують тестери) не можна втягнути в інтеграцію в цей понеділок, щоб гарантувати тестувальників стабільну базу коду для вирішення випуску.

Кожного вівторка:

  • Тестери перевірили галузь інтеграції настільки, наскільки вони, можливо, дають доступний час, і немає відомих помилок, тому випуск скорочується та витісняється до виробничих вузлів повільно.

На практиці це звучить нормально, але ми виявили, що цього досягти неймовірно важко. Команда бачить такі симптоми

  • "Тонкі" помилки виявляються на виробництві, які не були ідентифіковані в умовах постановки.
  • Останні хвилини гарячих виправлень продовжуються у вівторок.
  • Проблеми у виробничому середовищі вимагають відкотів, що блокує постійний розвиток до досягнення успішного розгортання в реальному часі, і головна галузь може бути оновлена ​​(а значить, розгалужена з).

Думаю, тестове покриття, якість коду, здатність швидко регресувати, зміни в останню хвилину та екологічні відмінності тут грають. Хто-небудь може запропонувати якісь поради щодо того, як найкраще досягти "постійної" доставки?


1
Далі на відповідь @ emddudley про книгу «Неперервна доставка» я б закликав вас переглянути infoq.com/presentations/Continuous-Deployment-50-Times-a-Складіть по-справжньому цікаву презентацію про справді багаторазове розгортання в реальному часі виробництво.
sdg

Відповіді:


6
  • "Тонкі" помилки знаходяться на виробництві, які не були визначені на сценічному середовищі - в одному з проектів з такими проблемами я бачив, що це досить успішно вирішувалося тактикою, яку я б назвав подвійними. Я маю на увазі для таких помилок, хлопці створили два квитки в трекері випусків: один був призначений розробникам для виправлення коду, інший тестерам для розробки та встановлення регресійного тесту чи зміни в постановочному середовищі, що не дозволить повторити його в майбутньому. Це допомогло тримати постановку досить близько, щоб продюсувати.

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

  • ентузіастичні гілки функцій - чи це означає, що певний час ви також намагалися працювати над однією гілкою і вважаєте її неповноцінною? Якщо так, тоді пропустіть решту. В іншому випадку спробуйте працювати над однією гілкою (якщо потрібно, Google для розгалуження стратегії "гілка розвитку" або стратегії розгалуження "нестабільний стовбур" для деталей). Або, якщо ви використовуєте Perforce, шукайте в Інтернеті інструкції Microsoft щодо розгалуження та злиття. Спробуйте я це сказав? Вибачте, відповідне слово повинно бути тестом : я маю на увазі, 1) план, коли і як виміряти, чи є одна гілка кращою чи ні тієї, яку ви маєте зараз, і 2) план, коли і як ви перейдете назад до функціональних гілок у випадку, якщо це тестування не вдається .


PS.

Напевно, ви можете знайти більше подібних хитрощів, пошукаючи в Інтернеті щось на зразок програмного забезпечення управління ризиками


оновлення

<копія з коментарів>

Я вважаю, що часті виправлення виправлень є симптомом розірваного трубопроводу - це не так? Так чи інакше, вони потребують повторних випусків, щоб отримати виправлені виправлення, зробивши більше роботи для команди ops. Крім того, гарячі виправлення зазвичай кодуються під екстремальним часовим тиском, це означає, що вони, швидше за все, будуть нижчої якості, ніж звичайні роботи.

</ копію з коментарів>

  • гарячі виправлення в останню хвилину - вищезазначені проблеми для мене виглядають розумно, а також ваша посилання на зламаний тестовий конвеєр. З цим оновленням вашого увагу , що до нової інтеграція коду блокується в понеділок звучить як ще один симптом зламані (я думаю , що більш точне слово буде стверджувало ) трубопровід. Під твердженням я маю на увазі наступне: ви використовуєте одну гілку, щоб одночасно служити двом цілям: інтеграції та випуску. Коли випуск підходить, ці дві цілі починають зіштовхуватися між собою, висуваючи суперечливі вимоги: цілі інтеграції найкраще обслуговуватись із постійно відкритою гілкою ( злиття рано та часто ), а вивільнення переваг стабільності від гілки запечатано(ізольовано) якомога довше. А-ха, схоже, що частини головоломки починають відповідати ...

.. Подивіться, що заморожування в понеділок зараз виглядає як компроміс, зроблений для забезпечення конфліктних цілей: розробники страждають від блоку інтеграції нового коду, в той час як тестери страждають від цього блоку занадто коротко, всі дещо нещасні, але обидві цілі служать більш-менш.

Ви знаєте, з урахуванням вище, я думаю, що найкращим варіантом буде спробувати звільнитись від спеціальної галузі (крім інтеграції) . Незалежно від того, чи буде ця галузь довго жити як інтеграція чи недовговічна, як ваші гілки функцій (з "функцією" є, ну, випустіть) - це вирішувати вам, це просто має бути окремим.

Просто подумайте. В даний час вам здається, що одного дня недостатньо для стабілізації стабілізації випуску, правда? з новою стратегією розгалуження, ви можете просто роздрібнитись за 2 дні до виходу замість однієї, без проблем. Якщо вам здається, що навіть двох днів недостатньо, спробуйте розблокувати 3 дні раніше, і т. Д. Справа в тому, що ви можете ізолювати гілку випуску вже як завгодно, оскільки це більше не блокує об’єднання нового коду до гілки інтеграції. Зауважте, у цій моделі взагалі не потрібно заморожувати гілку інтеграції - ваші розробники можуть постійно використовувати її в понеділок, вівторок, п’ятницю, будь-що.

Ціна, яку ви платите за це щастя, - це ускладнення виправлень. Вони повинні бути об'єднаними у дві гілки замість однієї (випуск + інтеграція). Це те, на що слід зосередитись при тестуванні нової моделі. Відслідковуйте все, що пов'язано - додаткові зусилля, які ви витрачаєте на злиття з другою гілкою, зусилля, пов’язані з ризиком того, що ви можете забути приєднання до другої гілки - все, що пов'язане.

Наприкінці тестування просто зведете те, що ви відстежили, і дізнаєтесь, чи є ці додаткові зусилля прийнятними чи ні. Якщо це прийнятно, ви закінчите. В іншому випадку поверніться до вашої поточної моделі, проаналізуйте, що пішло не так, і почніть думати, як ще можна вдосконалитись.


update2

<копія з коментарів>

Моя мета - перевірити і доставити історії (позаду або перед стіною конфігурації) в рамках ітерації, цього можна досягти лише в тому випадку, якщо тестувачі тестують роботу, виконану за ітерацією (а не стабілізуючи код з попередньої ітерації).

</ копію з коментарів>

Я бачу. Добре, що я не маю прямого досвіду з цим шляхом, але я побачив тестування тестування в ітерації, успішно виконане в нашому проекті. Оскільки наш проект йшов навпаки, я також мав розкіш порівняння віч-на-віч для цих протилежних підходів.

З моєї точки зору, підхід до тестування поза ітерацією виглядав вище в цій гонці. Так, їх проект пройшов нормально, і їхні тестери виявили помилки швидше, ніж у нас, але якось це не допомогло. Наш проект теж пройшов чудово, і якимось чином ми могли дозволити собі більш короткі ітерації, ніж вони, і у нас було менше (набагато менше) релізних релізів, ніж у них, і напруга між розробниками та тестерами була меншою.

BTW, незважаючи на швидке виявлення з їх боку, нам вдалося мати приблизно однаковий середній термін служби помилок (тривалість життя - це час між введенням та виправленням , а не між введенням та виявленням). Напевно, у нас навіть було незначне перевагу, оскільки за допомогою коротших ітерацій та менш ковзаючих релізів ми могли стверджувати, що в середньому наші виправлення досягають користувачів швидше, ніж їхні.

Підсумовуючи, я все ще вважаю, що виділення коду випуску має кращі шанси на підвищення продуктивності вашої команди.


на подальшу думку ...

  • Виділення кодової лінії випуску має більше шансів - після перечитування я відчуваю, що це може створити враження, що я відбиваю вас від спроб тестування на ітерацію . Я хотів би дати зрозуміти, що я цього не роблю.

У вашому випадку підхід до ітераційного тестування виглядає безпечним для спробу (е ... тест ), оскільки, здається, ви чітко розумієте, як цього досягти (плавний тестовий конвеєр ) та які основні перешкоди. Зрештою, у вас завжди є можливість повернутися до альтернативного підходу, якщо вам здається, що виправити цей трубопровід правильно.

BTW щодо перешкод, додаткові, які варто відстежувати в цьому випадку, будуть такі питання, як невміння відтворювати помилку на стороні розробника та пізно знаходити / запізнювати перевірку виправлення на стороні тестерів. Вони також можуть застрягти у вашому трубопроводі , як це відбувається зараз із виправленнями.


1
Дякуємо за вашу думку. Щодо розгалуження, то ми протестували ні. підходів (і справді я використовував у своїй кар'єрі ряд @ різних орґанів). Ми визначилися з чистим майстром, який представляє код на виробництві, галузь інтеграції (заснована від головного), яку часто розробляють усі розробники (в ідеалі кілька разів на день). Відділення інтеграції будується та перевіряється постійно, з частими автоматизованими розгортаннями. Я раніше намагався з великим успіхом забруднити магістраль. Наш сучасний підхід здається більш контрольованим. Ми використовуємо конфігураційні стіни для неповної, небажаної функціональності.
Бен

1
@maple_shaft добре вперше я побачив помилок, відкритих у трекері проти тестового набору, був у 2002 або 2003 роках. І це, здавалося, було досить усталеною практикою в команді, до якої я приєднався тоді. Що стосується націлювання на помилки, що відрізняються між продандом та постановкою, вони справді здаються мені новими , оскільки перший раз, коли я його бачив (і був дуже здивований), було менше 2 років тому
гнат

1
@gnat, Це здається здоровим глуздом, тому я дивуюсь, чому я раніше про це не чув. Тепер, коли я замислююся над цим, хоча це має сенс, тому що кожна група QA, з якою я коли-небудь працювала, здавалася, абсолютно рада радість виправляти помилок, але ставала кричущою дворічною, коли помилки будуть проти них.
maple_shaft

1
@maple_shaft lol згоден, такий спосіб видається незаслужено рідкісним. Чи знаєте ви, до речі, що помилки можна видавати не лише на тестерах, але і на документах до / spec? - Збірка 12 із посібника Dev говорить "чорне" на сторінці 34 рядка 5; має бути "білим". - Призначається Джону Сценаристу. - Виправлено в збірці 67. - Виправлено перевірку в збірці 89 Полом Тестер.
гнат

1
Моя остання відповідь, оскільки я не хочу перетворюватися на сеанс чату, але в останньому органі я написав помилку проти письменника-спеціаліста, і весь підрозділ відскочив у мить WTF. Мені оперативно сказали, що у мене "проблема зі ставленням" і що я не "гравець команди" і не робити цього знову.
maple_shaft

8

Не знаючи природи історій користувачів та їх кількості, я мушу сказати, що цикл випуску на 1 тиждень здається надзвичайним. Вищеописаний сценарій, який ви описали, складно спланований і включає низку різних гілок, точок злиття, відключення, оточення та тестових наборів, більш-менш створення людської системи, де одна помилка серед складності плану може спричинити пізнє звільнення або погана якість. Це може мати ефект доміно на наступні випуски.

ІМХО розклад просто занадто проклятий.

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

Ви можете підвищити якість коду, ввівши парне програмування та / або перегляд коду, хоча це з'їдає ще більше дорогоцінного часу.

Краща оцінка точок історії користувачів також може допомогти, неявно обмеживши розповіді користувачів, які входять до одного випуску, тим самим знизивши знаменник на коефіцієнт ризику.

В цілому, це здається, що у вас є хороші практики та у вас є гарна система, яка може керувати вашим екстремальним циклом випуску. Ви, здається, на правильному шляху.


Так! Один тиждень із великим продуктом на складеній мові, що потребує вітряних інтеграційних тестів, не є безперервним, але це посилюється . Тримайте це занадто багато, і ви збираєтесь зазнати смертності на роботі!
ZJR

+1; ми виконуємо тритижневі ітерації на даний момент, і виявимо, що це працює добре.
Duncan Bayne

@ ZJR, будь ласка, можете розширити те, що ви маєте на увазі, послаблюючи в цьому контексті?
Бен

@Duncan, наші ітерації є 2-тижневими, але ми намагаємось збільшувати тиждень . Це може бути, а може і не бути можливим / погана ідея. Мислення полягає в тому, що приріст на один тиждень буде містити менше нового коду і, отже, матиме менше проблем.
Бен

1
@Ben Aston, кількість коду не створює проблем, нереалістичні терміни, стрес та великі очікування створюють проблеми.
maple_shaft

1

Чому б не використовувати фактичне безперервне розгортання, коли фіксація (або натискання) викликає запуск тестів, а якщо тести проходять, відбувається розгортання?

Тоді, якщо ви не впевнені в зміні, ви робите це в окремій гілці, що все ще спричиняє запуск тестів, але не розгортання.

Я думаю, що більше намагань досягти стабільності пошкодженого ствола / господаря, ніж це, ви знаєте, просто підтримувати його стабільним.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.