Прості способи покращити якість випуску в середовищі RAD

Трохи передумови тут - ми невелика команда (з 5) розробників RAD, відповідальних за внутрішню розробку програмного забезпечення у великій непрограмній компанії. "Внутрішнє програмне забезпечення" варіюється від настільного додатка .NET, що використовує MSSQL-сервер як сервер для скриптів Python, що працюють на задньому плані до документів та шаблонів MS Word - зоопарку технологій.

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

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

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

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

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

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

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

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

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

Я бачив дуже обмежену літературу з цього приводу, це те, що ми практикуємо, що безумовно допомагає:

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

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

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

4. Відділення для розробки суттєвих особливостей
Все, що пов’язує зміни, які впливають на дизайн, потрібно робити окремо на гілці. Більша розробка не завершується швидко порівняно з меншими помилками. Якщо ми запровадимо проміжні комітети, де "часткова" робота, пов'язана з функцією, яка все ще не використовується, - це потенційна область введення помилок; помилки, які б не виникли, якби повноцінна робота над функцією завершилася б атомно - отже, це помилки, які нам би не довелося вирішувати, якби були гілки.

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

6. Розширення спочатку будь-якої нової версії на декількох клієнтів.
У нашому випадку ми спочатку бачимо тестування її на кількох сайтах, а всі інші сайти застосовують випуск лише тоді, коли на нього є попит. Багато разів деякі (або більшість) користувачів переходили б лише зі стабільного випуску до іншого стабільного випуску.

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

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

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

10. Останнє, але не менш важливе
Навчіться часто повертатися до білої дошки. Чим більше ви переосмислюєте, ніби ця функція була б частиною нашого найпершого дизайну, як би ми подумали про дизайн тоді? Іноді, найбільша проблема з поступовою роботою полягає лише в тому, що ми занадто обмежені набором функціональних можливостей, які ми створили першими, і часто не можемо повернутися до основ. Хитрість полягає в тому, щоб продовжувати бачити, як би ми узагальнили, а не вмістили цю нову функцію чи сценарій. Це вимагає, щоб дизайн залишався актуальним, і це трапляється лише в тому випадку, якщо ми часто повертаємося до малювальної дошки. Крім того, коли приєднуються програмісти нового покоління, вони стають частиною мислячого резерву, а не просто накладають патчі.

РЕДАКТИРУЙТЕ
11. Слідкуйте за пробілами в роботі та дизайні.
Досить часто ми перебуваємо під тиском строків, щоб виправити помилку та випустити у виробництво. Однак, коли помилка на рівні дизайну, потрібно змінити декілька речей, але часто люди виправляють деякі скорочення, щоб дотриматись терміну. Це нормально . Однак, коли кількість таких рішень навколо рішень збільшується, код стає крихким. Слідкуйте за тим, скільки недоліків у дизайні вже пройшло. Як правило, коли ви домовляєтесь про терміни з менеджером проекту, найкраще змусити його / її взяти на себе зобов’язання, що ми доставимо це в короткостроковому режимі, щоб заощадити виробництво, але у нас також буде хронологія та ресурси для отримання постійного рішення.

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

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

Відставання | Робити | Зроблено

Однак це швидко розвинулося, щоб відобразити наш фактичний процес:

Відставання | Розробка | Дев. Тест | УАТ | Виконано | Випущено

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

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

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

Інші посилання, які я вважаю корисними:

Kanban застосовується до розробки програмного забезпечення: від Agile до Lean

Система Kanban для інженерії програмного забезпечення - Відео

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

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

• Lean Development Software від Мері та Тома Поппендейка дає можливість читати людям, зацікавленим у тому, щоб дізнатися, як визначити "відходи" та що робити з тим, щоб змінити процеси, щоб стати швидшими та ефективнішими.
• Перший керівник розробки програмного забезпечення від Дена Пілоне та Русса Майлза на перший погляд трохи схожий на одну з тих книг "для муляжів", але, оглянувши трохи минулий хаотичний стиль викладу, він містить більшість інформації, що стосується основ програмної інженерії і має короткий опис про тестування керованої розробки.
• Представляючи BDD, це сторінка Дана Норта про те, як вступити в розвиток поведінки, або, можливо, ви віддаєте перевагу BDD Wiki . Це початкові посилання на BDD, і ви, ймовірно, захочете заглянути в інструменти та рамки, які допоможуть вам. Важливо розуміти, що BDD ефективно TDD піднімається на більш високий концептуальний рівень. Це дозволяє думати про тестування, як ви думаєте про технічні характеристики, і тестувати тією ж мовою, якою ви користуєтесь, коли пишете специфікації. Рамки, як правило, інтегруються з іншими блоками тестування одиниць, тому ви отримуєте найкраще з обох світів, якщо вирішите, що ваше тестування може не мати вигоди від синтаксису BDD.
• Стаття про гнучку розробку програмного забезпечення Вікіпедії - це хороший буквар, що стосується спритної розробки програмного забезпечення та містить низку корисних посилань та посилань на статті деяких більш шанованих людей спільноти розробників.

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

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

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

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

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

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

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

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

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

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

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

Для програм C / C ++ я виявив, що додавання тверджень для тестування розподілу пам'яті було дуже корисним для зменшення кількості витоків пам'яті в програмі.