Як я можу автоматизувати виробничі розгортання, не відчуваючи особливої ​​тривоги?

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

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

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

Я, як правило, не контролер, але завжди відчуваю ненаситну потребу в розгортанні виробництва на виробництво вручну. Я чув від колег, що це, як правило, справді BAD Thing ™, але вони не спромоглися виступити проти цього.

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

Які аргументи проти цього АБО аргументи для автоматичного розробки сценарію виробництва?

Проти цього є кілька очевидних аргументів.

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

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

3. Час. Оскільки розгортання ускладнюється, кількість, яка потребує виконання, збільшується. Сценарії вимагають лише початку, ручної перевірки, а потім переключення вручну (ви також можете це автоматизувати, але я поділяю частину параної :).

Ви можете отримати найкраще з найкращих світів: спокій з перевіркою процесів та надійність автоматизації.

Сценарій розгортання. Потім перегляньте та вручну перевірте, чи запускаються процеси, видаляються файли тощо. Іншими словами, напишіть власний QA-скрипт лише для того, щоб переконатися, що автоматизовані кроки 1 - X насправді відбулися.

Я думаю, що тут головне: чому ти вважаєш, що не можеш скриптувати процес перевірки?

Мої сценарії розгортання не просто натискають архіви та перезапускають служби. Вони друкують багато кольорової інформації під час кожного кроку розгортання та надають мені підсумок подій наприкінці. Це дає мені знати про те, що процеси працюють і працюють, що домашня сторінка обслуговує код статусу 200, і що всі машини та сервіси можуть бачити один одного. Потім у мене є окремий сервіс, який не є частиною скрипту, який відстежує файли журналів, помилки рівня 4xx та 5xx та ключові показники сайту. Потім він кричить на мене через кожен можливий носій (електронна пошта, txt msg та тривоги), якщо є різкі сплески негативного ефекту.

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

Ви також повинні бути.

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

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

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

• У вас немає хорошого журналу, історія оболонок не враховується
• Ніхто більше не знає, як це зробити
• Кроки пропущені
• Перевірки робляться лише іноді
• Деякі елементи для розгортання можуть бути пропущені, я це робив раніше
• Це займає набагато довше
• Ви можете перерватися під час процесу

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

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

Автоматизований сценарій також є доброю річчю ^ТМ, і поки ви обережно підходите до нього, ви повинні мати можливість мінімізувати небезпеку і знизити свій страх. Тож моя порада така;

• Підготуйте (і практикуйте інтеграцію env) контрольного списку / набору тестів, щоб ви могли швидко дізнатися, чи працював він, і що, якщо щось пішло не так. Докладний журнал може допомогти у цьому.
• Створіть резервну копію всього. Підготуйте та практикуйте ручний відкат, щоб ви могли відновитись, якщо піде не так.
• Випробуйте стільки, скільки зможете, перш ніж зробити це на реальному продажі. Здається, ти добре допомагаєш разом із цим зі своєю інтеграцією.
• Перший раз, коли ви спробуєте це, зробіть це на низькому рівні, із низькою зміною впливу. Щось на зразок незначного оновлення чи виправлення. Ідея полягає в тому, щоб мінімізувати випадання, якщо воно піде не так. Не вибирайте головне оновлення з високим рівнем профілю (де спостерігають генеральний директор та всі ваші конкуренти) для першого запуску.

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

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

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

З цього приводу, ось деякі основні вказівки щодо автоматизації виробничих розгортань:

• Не робіть це все відразу! Почніть повільно писати свої автоматизовані розгортання. Спершу створіть окреме невиробниче середовище та спробуйте автоматизувати розгортання там. Щойно ви створили впевненість у своїх автоматизованих розгортаннях, ви можете почати замислюватися над тим, щоб робити виробничі розгортання
• Почніть випускати та розгортати дуже часто! Набагато простіше робити автоматизовані розгортання, коли у вас немає 4-місячного коду, який чекає виходу. Випускайте невеликі функції та виправлення помилок кілька разів на тиждень. Переваги цього стилю випуску не можна занижувати!
• Покладайтеся на автоматизовані тести, щоб ви впевнені, що ваше виробниче середовище буде працювати. Знову ж таки, це потребує часу для нарощування, але це дуже важливо. Автоматизовані тести завжди кращі, ніж тести прийняття вручну. Звичайно, тести приймання вручну - це нормально, але автоматизовані тести можуть допомогти вам дізнатися, чи слід застосовувати виробництво чи ні. Вони є тим ключем, що дозволяє забезпечити весь цей процес автоматизованої безперервної доставки. Якщо ваші тести не пройдуть, ви знаєте, що не використовувати в виробництві.

Запустіть сценарії на реальному сервері. Це спрацює, і, побачивши, як він працює кілька разів, ви будете абсолютно впевнені в цьому.

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

Комп'ютери не помиляються, люди роблять.

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

Зробіть це вручну, і ви зобов’язані робити помилки. Можливо, ви написали, все, що вам потрібно зробити, вниз, але це так просто помилитися. Ви повинні скопіювати всі файли, крім файлу web.config? Ви можете зробити ставку, що коли-небудь ви його перезапишете. Сценарій ніколи не помилиться.

Як я можу автоматизувати виробничі розгортання, не відчуваючи особливої ​​тривоги?

Надзвичайна тривога, яку ви відчуєте при автоматизації розгортання виробництва, найімовірніше, базується на двох переконаннях:

1. Одного чи іншого дня деякий крок розгортання не вдасться, і ви або інша людина здатна швидко відновитися після відмови, в той час як автоматичний скрипт міг би його не помітити.

2. Помічений провал у виробництві має драматичні наслідки.

Мало що може зробити близько 2. Окрім уникнення невдач, тому зупинимось на 1.

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

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

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

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

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

Враховуючи вище, я, мабуть, був би таким же тривожним, як і ви.

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

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

• В одному з проектів я допомагав їм у розгортанні як представник команди розробників. До розгортання вони переглядали мої вказівки, і під час розгортання я просто сиділа в Інтернеті, готова проконсультуватися, якщо все піде не так. Тоді я навчився цінувати цю розлуку .
   
  Не те, щоб вони були швидшими (чому б це зробити? Я тестував розгортання 5x-10x частіше, ніж вони). Велика різниця полягала у фокусі. Я маю на увазі, мою голову завжди завантажують "основні" речі - кодування, налагодження, нові функції - просто занадто багато відволікань, щоб правильно сконцентруватися на розгортанні. На відміну від цього, їх головним завданням було лише обслуговування виробництва, і вони були зосереджені на цьому.
   
  Дивно, наскільки краще працює мозок, якщо зосереджений. Ці хлопці, вони були просто набагато уважнішими, вони робили набагато менше помилок, ніж я. Вони просто знали, що це краще, ніж я. Вони навіть навчили мене речі чи дві, що полегшило мої власні тестові розгортання.

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

1. Спростіть. Ваш процес зміни повинен бути rsync-файлами, запускати SQL-скрипт, нічого більше.
2. Автоматизувати.
3. Тест.

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

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

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

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

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

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

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

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

1. вперше візьміть більше вікно для розгортання, якщо все піде не так

2. Розділіть процес розгортання на дві частини. а. Резервне копіювання (вручну) - це повинно дати вам впевненість, якщо під час розгортання щось піде не так

   б. Розгортання (автоматизоване)

як тільки ви зможете вперше розгорнутись із впевненістю. Ви також можете автоматизувати процес резервного копіювання.