Чи найкраще розгортати проект до серверного файлу за файлом вручну?

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

Яка найкраща практика? щоб вручну розгорнути один артефакт проекту кожного розгортання або продовжувати робити файл за допомогою розгортання файлів?

Ні.

Найкраща практика - автоматизація розгортання повністю та виключно. Це означає, що ніхто не може нічого ставити на сервер вручну.

"Узагальнити підсумок резюме: Люди - це проблема." (Дуглас Адамс)

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

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

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

Найкращою практикою було б запровадити якийсь автоматизований процес.

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

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

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

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

Найкращою практикою буде аналіз витрат / вигод для конкретного розгортання для вашої конкретної компанії.

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

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

Відтінків сірого між ручним копіюванням за файлом та постійною доставкою є безліч відтінків сірого.

Почніть із зменшення складності процесу розгортання, наприклад, використовуючи поштовий файл, упаковку в стилі rpm, інфраструктуру як інструмент управління кодом (наприклад, ляльковий або шеф-кухар) або навіть просто простий скрипт, який копіює файли для вас із Постановочна область на ftp-сервері.

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

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

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