DevOps - автоматизуй все
Метою статті є дати основні уявлення про DevOps та практики, що використовуються при цій методології. Тут не буде складних термінів, конкретних продуктів та road map впровадження DevOps, але, сподіваюся, буде цікаво ознайомитись.
Тут описані такі:
Структура статті побудована таким чином: перераховано практики, дано їх опис, наведено Бізнес-Значення практики (те, як впровадження цього підходу покращить життя бізнесу) та Вимірюваність (як можна виміряти покращення). І Бізнес-значення, і Вимірюваність також взяті із презентацій «DevOps-Fundamentals».
Ну що ж, приступимо. Процес розробки та постачання програмного забезпечення складається з наступних кроків:
Починається все із планування. Планування релізу, розробки, тестування, розгортання. Пропустимо цей крок, тому що розробка і операції в цьому етапі не задіяні. Після того, як розробник закінчив реалізацію певної ділянки коду, він зберігає (commit'it) його в систему контролю версій. Після цього вступає у справу перша практика:
Безперервна інтеграція (Continuous Integration)- це практика розробкипрограмного забезпечення, яка полягає у злитті робочих копій у загальну основну галузь розробки кілька разів на день та виконання частих автоматизованих збірок проекту для якнайшвидшого виявлення та вирішення інтеграційних проблем. Wiki
Що таке Continuous Integration? Процес відбувається приблизно так: розробник після того, як завершив своє завдання і налагодився, зберігає свої зміни в робочу копію (TFS, SVN, Git). Далі в дію вступає якийсь робот (TFS, TeamCity, ще), що відстежує зміну робочої версії. Він бачить, що робоча копія змінилася та запускає складання проекту. За результатами складання, повідомляється розробник (та інші зацікавлені особи) про те, чи все успішно пройшло чи ні. Повідомлення може бути через лист, повідомлення в треї, або відобразитися на веб-сторінці. Таким чином, якщо збірка пройшла з помилкою, то розробник одразу дізнається про це.
Бізнес значення
Вимірність
Автоматичне тестування (Automated Testing)
Після того, як збирання зібрано, її потрібно перевірити. Найшвидше це можна зробити за допомогою автоматичних тестів. Для цього використовуються різні інструменти: це можуть бути тести Unit, UX тести, інтеграційні тести. Головна умова – вони повинні вимагати участі людини. За допомогою авто-тестів ми одразу отримуємо інформацію про те, чи є помилки в нашій збірці. І відразу можемо почати їх виправляти, не чекаючи результатів ручного тестування.
Бізнес значення
Вимірність
Інфраструктура як код (Infrastructure as Code)
Інфраструктура як код— це процес управління та підготовки обчислювальної інфраструктури (процеси, фізичні сервери, віртуальні сервери тощо) та їхконфігурації через машиннооброблювані файли визначень, а не фізичну конфігурацію обладнання або використання інструментів конфігурації Wiki.
Підхід до конфігурування програм повинен бути таким самим, як і до коду. Тобто конфігураційні файли, змінні оточення, щось ще повинні зберігатися в централізованому сховищі або системі контролю версій, можливо, в тій самій, що зберігається код. І при конфігуруванні програми братися вони мають саме звідти. Відповідно, у разі потреби змінити конфігурацію на сервері, відповідальний співробітник не заходить на нього і змінює, наприклад, з'єднання до БД, а змінює потрібну змінну в сховище, і звідти вона автоматично з'являється на сервері.
Для змінних, специфічних для різних середовищ (Dev, Stage, Production) використовуються синоніми, які підмінюються при розгортанні реальні значення. Прикладом такої заміни може бути технологія transform, використовувана зміни конфігураційних файлів .NET додатків.
Звички (Habits)
Бізнес значення
Вимірюваність
Безперервне розгортання (Continuous Deployment)
Безперервне розгортання – об'єднання Continuous Integration (безперервної інтеграції) та Continuous Delivery (безперервного постачання). Це наступний крок після успішного складання та успішного проходження автоматичних тестів (і, можливо, встановлення галочки «складання готове до розгортання» відповідальною людиною). Якщо ви впевнені у ваших тестах, їх наборі та покритті, при їх успішному виконанні запускається автоматична установка на відповідне середовище, тестове або продуктове. Різниця між Continuous Integration, Delivery, Deployment добре описана тут: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
Бізнес значення
Вимірність
Управління релізами (Release Management)
Управління релізом полягає в тому, що ми визначаємо формальні критерії, чи готове збирання до встановлення на відповідне середовище. Прикладом критеріїв, за якими складання готова, і, якщо вони виконуються, автоматично запускається поставка (Continuous Deployment) може бути:
Бізнес значення
Вимірність
Управління конфігураціями (Configuration Management)
Тут до формального визначення додати особливо й нема чого. Все має бути записано та підраховано.
Бізнес значення
Вимірність
Навантажувальне тестування (Load Testing)
Навантажувальне тестування(load testing) — підвид тестування продуктивності, збирання показників та визначення продуктивності та часу відгуку програмно-технічної системи або пристрою у відповідь на зовнішній запит з метою встановлення відповідності вимогам до цієї системи ( пристрою) Wiki
Часто відбувається так, що, наприклад, для web додатків, коли користувач один (розробник або тестувальник) сторінка швидко відкривається і добре реагує на роботу з нею. Але як тільки зміни потрапляють на продуктовий сервер, і цю сторінку починають дивитися сотні, тисячі чоловік одночасно, сторінка довго вантажиться і перестає реагувати. Проводячи навантажувальне тестування ми визначаємо наявність проблем на ранньому етапі, ще до потрапляння проблемного складання на продуктовий сервер. Навантаження тестування реалізується генерацією великого потоку запитів до сервера та аналізу поведінки сервера.
Бізнес значення
Вимірність
Моніторинг швидкодії програмиApplication Performance Monitoring
Моніторинг швидкодії програми(application performance management) – це моніторинг та управління швидкодією та доступністю ПЗ. APM прагне виявляти та діагностувати проблеми швидкодії комплексно, для підтримки очікуваного рівня обслуговування Wiki
Навантажувальне тестування виявляє багато проблем ще до того, як збирання потрапило на продуктові сервери і з нею почали працювати клієнти. Але, на жаль, не завжди вдається передбачити як дії користувачів, так і вплив різниці в ресурсах серверів на тестовому та продуктовому середовищі. Тому необхідно моніторити стан та роботу програми на продуктовому середовищі. Цьому і служить моніторинг швидкодії програми.