Однотижневий цикл випуску: як зробити це здійсненним?

У моєї компанії (3-річна стартап веб-індустрії) у нас виникають часті проблеми з командою продукту: "Аааа, це зараз криза!" (не всі?)

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

Є 13 розробників та 6 місцевих / 9 офшорних тестерів; теорія полягає в тому, що лише 4 розробники (і всі тестери) будуть працювати над випусками з парними номерами, якщо тільки не з’явиться робота, яка справді вимагає певного досвіду одного з інших розробників. Кожен цикл буде містити два дні роботи з розробниками та два дні роботи з забезпечення якості (плюс 1 день визначення / триагу / ...).

Мої запитання:

(a) Чи має досвід хтось із таким тривалістю циклу випуску?

(b) Хто-небудь чув про такий тривалість циклу випуску навіть намагався?

(c) Якщо (a) або (b), як на Землі ви це змушуєте це працювати? (Будь-які підводні камені, яких слід уникати тощо) також оцінені.)

(г) Як ми можемо мінімізувати шкоду, якщо ці зусилля не вдаються?

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

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

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

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

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

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

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

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

Пам’ятайте, якщо ви постійно поспішаєте вносити зміни, ви набагато більше шансів помилитися в цих змінах і зламати щось інше, роблячи це.

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

Є компанія, яка випускає 50 разів на день. У цій публікації блогу описано, як вони це роблять .

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

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

(а) + (б) ІМХО, відповідно до чисельності вашої команди, максимум два тижні. Один тиждень буде працювати для представників одного чоловіка або дуже крихітних команд (наприклад, 2 або 3).

(c) + (d) Але незалежно від розміру вашої команди чи проекту, першим, що я роблю, є автоматизація збирання та розгортання. Я економлю дні, якщо не тижні роботи, роблячи це в перші дні проекту.

Розгортання потрібно виконати одним клацанням миші. Від джерела до постановки, потім від постановки до виробництва. Існує маса інструментів, щоб зробити це можливим. Від мураха / нанта до надважких речей, як Automated Build Studio .

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