Як передавати файли у виробництво?

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

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

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

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

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

Це звучить трохи повільно, в тому сенсі, що цикл зворотного зв'язку є відносно великим. Але для правильного тестування важливо зробити фіксований знімок, який потім досліджується протягом 24-48h (а може і більше, залежно від розміру проекту). Навпаки - це сценарій, коли ви виявляєте багато помилок відразу після натискання, і ви намагаєтеся виправити це декількома швидкими виправленнями, які впроваджують нові помилки.
Вам краще зробити реліз із відомими помилками (прийнятної серйозності), ніж з невідомими помилками (невідомої серйозності).

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

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

Залежно від платформи, яку ви використовуєте, існує багато інструментів, які можуть мати сенс використовувати для автоматизації виробничих версій. Я працюю в магазині .NET, тому ми використовували NAnt (хоча MSBuild є кращим варіантом на сьогодні). У Яви є Мурашка, а можливо й інші речі. У Рубі є такі речі, як Рейка. Потім існують платформи безперервної інтеграції, такі як TeamCity та Hudson, які також можна використовувати для управління випусками.

Я ніколи не бачив і не чув, щоб прод-код знаходився безпосередньо в окремому репо-контролі джерела, але це, безумовно, може працювати. Як сказав back2dos, ключовим є автоматизація. У нас є сценарії побудови, призначені для перевірки контролю над джерелами, побудови та переходу на інсценування для тестування. Потім, коли нам подобається, як працює постановка, сценарії копіюються з QA в Prod.

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