ІТ Компанії з настроннимі надійними інструментами реліз-менеджменту сьогодні мають дуже вагому конкурентну перевагу. У цій статті Surinderpal Kumar розповідає про трьох основних трендах в управлінні релізами, від яких може виграти будь-яка ІТ компанія.
У зв'язку зі збільшенням тиску з боку ринку, компанії всіма силами намагаються випускати їх продукти раніше конкурентів. Такі часті релізи дозволяють командам перевіряти функціональність раніше і легше виявляти помилки. Крім того, менший релізний цикл дає більшу гнучкість, дозволяючи вносити непередбачені спочатку зміни без зайвих витрат. В результаті, компанії з такою системою релізів отримують значну конкурентну перевагу.
Процес впровадження таких методик, проте набагато простіше описати словами, чим реально впровадити в компанії, оскільки з кожним днем розробка софта стає все складніше і складніше. Як мінімум через те що постійно з'являється все більше застарілого коду, змінюються ресурси, з'являються команди, розподілені по всьому світу, збільшується кількість підтримуваних платформ. У цій статті я розповім про три основні тренди, від яких може виграти будь-яка ІТ компанія.
Перший тренд: впровадження гнучких методологій на рівні ядра, включаючи автоматизацію. Просто щоранку проводити стендап-мітинги буде недостатньо. Так, планування спринтів і ітерацій разом з рев'ю і ретроспекцией теж важливі елементи для успішних релізів. Однак, для того щоб випустити істотні, значимі історії або фичи за відведений на спринти час, компанії змушені інвестувати в автоматизацію.
Відсутність автоматизації призводить до навантаження на вашу команду розробників і вносить людський фактор у ваше оточення, що впливає як на швидкість і ефективність роботи команди. Правильна автоматизація сформує незмінний повторюваний процес, який зменшує кількість помилок і час релізу. Гнучкі методології - будь то scrum або lean - все вкрай рекомендують автоматизувати складання, автоматизацію тестів, автоматизацію відвантаження / деплоя, і автоматизацію рев'ю / зворотного зв'язку. Особливо важливо, що автоматизація звільняє команди розробки від зайвої роботи по ручної конфігурації, дозволяючи зосередитися на коді і розробці продукту.
Наприклад, як тільки розробник коммітов зміни в систему контролю версій, зміни автоматично інтегруються з іншими модулями. Потім вже зібране додаток автоматично розміщується на тестовій середовищі. Зібрані модулі потім автоматично деплоятся на тестову середу. Якщо були зміни в платформі або оточенні, ці зміни автоматично білд і переносяться на тестову платформу. Наступним кроком автоматично проводяться тести застосовності такої збірки, в які також входять тести продуктивності, надійності і ємності. Розробники та / або керівники повідомляються лише в разі помилок. Однак, основний акцент залишається на розробці ядра, а не просто на додаткової зайвої активності. Звичайно, якісь ручні перевірки в будь-якому випадку залишаться, їх потрібно буде проводити команді реліз-менеджерів, щоб переходити до наступних кроків, але майже вся діяльність в рамках процесу деплоя може бути більш-менш автоматизована.
У міру проходження QA тестів, реліз версії продукту автоматично передається в релізний репозиторій з якого нова версія може бути запуліть автоматично іншими системами або може бути завантажена клієнтами. Існує цілий ряд технологій, доступних на ринку в кожному з цих розділів, включаючи автоматизацію білдів (наприклад Ant, Maven, Make), безперервну інтеграцію (Jenkins, Cruise Control, Bamboo), автоматизацію тестування (Silk Test, EggPlant, Test Complete, Coded UI ), і безперервний Деплой (Bamboo, Prism, Jenkins). Впровадження best practices зазвичай вимагає стратегічного планування та інвестицій часу на ранніх стадіях вашого проекту. Але це зменшить організаційні витрати і витрати на впровадження змін на наступних стадіях.
Другий тренд - використання віртуалізації і хмарних платформ як розробницького і тестового середовища. Сьогодні велика частина софта збирається з підтримкою декількох платформ, будь то операційні системи, сервери додатків, бази даних або інтернет-браузери. Команди розробки потребують тестування їх продуктів у всіх цих середовищах до того як випустити їх на ринок.
Однак, виникають труднощі зі створенням всіх цих середовищ, також як і їх підтримка. Ці труднощі підвищують складність, особливо в зв'язку з тим що команди розробки і тестування стають все більш географічно розподіленими. В таких умовах, використання віртуалізації і хмарних платформ може бути дуже зручним, і такі платформи останнім часом широко розгорнулися в ІТ галузі.
У деяких компаніях, команди реліз-менеджерів починають переносити автоматизацію деплооя на віртуалізовані і хмарні платформи. В цьому випадку, так само, як ми підтримуємо історію змін коду і конфігурації додатків, точно також ми підтримуємо історію версій всіх підтримуваних платформ.
Наприклад, раніше ми описали процес перевірки коду розробником, і автоматичного запуску билда і деплоя на необхідні тестові середовища. Схожим чином, якщо реліз або білд-інженери змінюють конфігурацію цільової платформи (ОС, БД, або настройки сервера додатків) - вся платформа цілком може бути сбілдена і образ системи створюється і деплоітся на відповідні платформи. Іншими словами, якщо ви використовуєте віртуалізацію VMWare, віртуальна машина автоматично розгортається з образу базової операційної системи, які підходять конфігурації викладаються і решта платформи і компонентів додатка деплоітся автоматом.
Те ж саме стосується і хмарного оточення (як IaaS, так і PaaS). Як тільки з'являються нові конфігурації - піднімається новий інстанси, конфігурується як середовище розробки і тестова середу. Це критично для продуктивності, інакше це може займати тижні щоб адаптуватися до змін конфігурації. З автоматизацією, процес стає повторюваним, швидким, і немає ніяких підводних каменів в комунікації між різними командами розробки.
Третій тренд - використання распределнних систем контролю версій. Подібні системи, як git, mercurial, perforce - стають все більш і більш популярними завдяки тій гнучкості, яку вони дають командам, щоб взаємодіяти на рівні коду. Фундаментальна основа таких систем полягає в тому, що кожен користувач тримає у себе версію сховища з усією історією на своєму комп'ютері. Немає необхідності в окремому майстер-репозиторії, проте велика частина команд використовує його все одно як best-practice. Розподілені системи дозволяють програмістам працювати офлайн і коммітов зміни локально.
Як тільки розробники завершують свою частину, вони пушаться їх зміни в центральний репозиторій як RC. DVCS надають фундаментально новий підхід взаємодії, такий що кожен розробник може відправляти свої зміни часто, без впливу на основну базу коду або транк. Це дуже корисно, коли команди досліджують нові ідеї або експерементують.
DVCS стають зручними для команд розробників, які використовують гнучку засновану на фічах стратегію гілок. Це надихає розробників продовжувати працювати над їх гілками (фичами) до готовності, повністю тестувати зміни локально, потім завантажувати їх в релізний ланцюжок. У цій схемі, розробники можуть працювати і Мержа один з одним фичи в локальній копії сховища.
Тільки після стандартних рев'ю і QA тестів - зміни мержатся в головний репозиторій. Якщо розробка вашого софта включає в себе кілька проектних команд, розподілені команди або розробку засновану на фічах - DVCS обов'язково потрібно взяти до уваги.
Впровадження цих трьох головних трендів в реліз-менеджменті створює дуже непоганий заділ на майбутнє для будь-яких ІТ компаній.