Я не люблю стрес, не люблю незворотні дії, і не люблю повторювати одну й ту саму роботу. Вочевидь, ніхто не любить, але чомусь у кожному проекті, де я приймав участь за останні 10 років, деплой найбільше непокоїв саме мене. :) І тож моя опінія — деплой повинен бути такої складності, щоб 10 раз за день не ставали додатковим навантаженням на когось, окрім системи CI.

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

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

Що треба, щоб стало норм? Дивись чекліст! Він упорядкований, кожен крок наближує до ідеалу.

• Скрипт, який буде генерувати артефакт, який буде запускатися: архів, пакет, уберджар, докер-файл.
• CI, налаштованний так, щоб цей скрипт запускався на кожен тег гіта (ну або взагалі на кожен комміт і далі автоматично все викочувати на стейджинг).
• Сценарій деплоя без даунтайму. Забрав сервер з балансування, перезапустив процес, увів назад. Або запустив нові контейнери, перевів балансування на них, повимикав старі.
• Цей сценарій повинен запускатися з якогось зрозумілого місця, а не з ноута якогось чувака. Скажімо, з кнопки у гітлабі, з команди в слаку, щось таке.
• Ось тут вже змінюємо процес і починаємо релізити частіше. Або прям кожну фічу окремо, або кілька. Ми у середньому робимо 9 релізів на тиждень.
• Трекінг помилок на продакшені з нотіфікашками про нові — ну типу Sentry. Воно вже і так повинно було бути, але все ж нехай буде. :)
• Сценарій ролбеку — релізу якоїсь з попередніх версій. Якщо можна швидше, ніж свіжий деплой, то так і треба робити. Це для зменшення стресу, щоб не так страшно було великі зміни релізити. Тіки помилки почали лізти, пішов, стару версію викотив, і можна спокійно розбиратися.
• Опціонально: якщо ви розробляєте гілками у гіті, навчитися легко викочувати ті гілки на окремі піддомени, щоб тестувати і дивитися до мержу у мастер.

Ну й не забувайте просту істину: мізки треба вмикати все одно. Головне — не пройти чекліст 1-в-1, головне — щоб стало добре. :)