Чи обмежений DevOps компаніями, що мають продукцію SaaS?

Практики, що описують DevOps, такі як безперервна доставка, автоматизація тощо, стосуються продуктів, які надають постійне обслуговування, таких як продукти SaaS.

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

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

Абсолютно не!

DevOps - це руйнування традиційних силосів (відділень) для підвищення ефективності.

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

Раніше я працював у великій медіа-компанії, де ми б підтримували внутрішній інструмент та розробляли публічні веб-сайти.

Переваги DevOps в нашому випадку полягали в наступному:

• Завдяки безперервній розробці ми повідомляємо команду розробників раніше, ніж пізніше, якщо є інтеграція або створюються проблеми з їх кодом. Вони можуть виправляти проблеми, поки їх розум все ще знаходиться на тій частині коду, яку вони тільки що здійснили.
• Завдяки безперервному тестуванню та доставці (в QA) ми дали змогу команді QA знайти проблеми раніше та повідомити про них раніше. Це скоротило час, необхідний для пошуку та виправлення помилок, а також зменшило складність цих розслідувань.
• За допомогою інструментів збору та збирання журналів ми надавали розробникам доступ до того, на що вони зазвичай не дивляться (вони дуже захоплюються налагодженнями :) - розуміння того, як журнали бачать і використовуються іншими командами, покращило загальну якість журналів
• Ми часто ділилися інформацією та створювали документацію для обміну знаннями між командами, намагаючись зруйнувати стіни. Розуміючи потреби Ops, ми створюємо кілька посібників про те, що завжди слід пам’ятати під час завантаження програми (де / як керувати властивостями тощо). Розуміючи реальність Dev (код більше функцій, швидше, gogogogo!), Ми змогли оперативники створити сервери та кластери, які краще підходили до потреб розробників.
• Загальна якість розгортань також значно покращилася. Розгортанням займалася наша команда, тому ми мали ідеальну видимість як на Ops, так і на Dev. Це усунуло багато проблем, пов’язаних із "передачею коду", де розробник передав пакет і односторінковий документ операторам із зазначенням "Встановити це!".

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

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

Нам все ще потрібно підтримувати надійний конвеєр розвитку, щоб обробляти постійний зворотний зв'язок від наших клієнтів, щоб переконатися, що ми доставляємо їм щось надійне та перевірене.

Хоча клієнт не дбає про DevOps (у більшості випадків), він все ще корисний для нас. Завдяки DevOps ми можемо швидко просувати нові збірки, тому клієнти можуть бачити зворотній зв'язок за хвилини, а не години, і ми також можемо виявити будь-які помилки / помилки за допомогою нашого тестування за допомогою Jenkins / Travis.

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

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

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

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

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

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

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

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

Тож методика корисна не тільки в SaaS.

Зовсім ні. Хоча на цій темі вже є чудові приклади, я хотів би поділитися власним анекдотом. У 2001 році я успадкував програмний проект з випуском, який передбачав створення компакт-диска. Документація для процесу випуску включала 40 (!) Кроків, задокументованих попереднім інженером, які включали деякі смішні вручну написані інструкції, такі як "відкрити цей файл конфігурації та змінити ім'я .jar-файлу в рядку 41, щоб включити номер версії новий реліз ".

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

Після того, як цей процес був автоматизований, ми придбали компакт-диск Jukebox. Щовечора після того, як тести проходили, машина збирання автоматично створила новий інсталяційний компакт-диск. Наші тестери могли прийти наступного ранку, взяти диск і переконатися, що все встановлено.

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