У будь-якому виробничому процесі, до якого відноситься і розробка програм, є різні етапи. Грубо кажучи, їх можна представити так:
- Виробництво (розробка)
- збірка
- Контроль і випробування
- доставка
виробництво
Місце, в якому відбувається цей процес, називається середовищем розробки, яка, як правило, є локальною. Навіщо потрібне якесь спеціальну назву? Щоб це зрозуміти, потрібно розглядати ситуацію в цілому. У нас завжди, як мінімум, є два середовища. Одна - це середовище розробки (її часто називають development environment), а інша - це середовище експлуатації (так кажуть рідко, зазвичай бойова среда, production). І код повинен вести себе по-різному в залежності від середовища.
- У середовищі розробки ширше рівень логгірованія, тобто ми бачимо все налагоджувальні повідомлення і вони нам допомагають розробляти. У продакшені цей рівень відключають, так як дуже швидко летить місце на диску.
- У середовищі розробки ми не можемо слати листи по-справжньому. Якщо це станеться, то ваші користувачі не будуть раді. До речі, це часто буває у тих, хто не налаштовує різні середовища.
- У середовищі розробки відключають кешування (техніка для прискорення доступу).
- Середовище розробки може містити неробочий код і знаходиться в неконсістентном (неузгоджену) стані. Це нормально, адже ми розробляємо.
Крім цього, код в середовищі розробки зазвичай пишеться не в основний гілці вашої системи контролю версій, а в гілці-фиче. Це важливо, тому що не блокує можливість робити швидкі правки, якщо на сервері щось поламалося, і потрібно поправити тільки невеликий шматок, а нові напрацювання ви ще не готові виливати.
На жаль, в середовищі php, до сих пір часто зустрічається ситуація, при якій розробка ведеться прямо в бойовому середовищі. Що призводить до дуже сумних наслідків.
Після того, як ви реалізували своє завдання (фичу), і вона була протестована, код завдання вливається в основну гілку і відбувається так звана інтеграція. Ця назва пов'язана з тим, що, можливо, крім цієї фічі, паралельно велася розробка іншої фічі, в іншій гілці, і з високою ймовірністю ту задачу виконували навіть не ви. І ось тепер в основний гілці вони зустрілися, а працюють вони разом чи ні - ще належить з'ясувати.
(Цей пункт сильно залежить від того, який процес обраний в конкретній команді).
Контроль і випробування
Зазвичай тестування включає в себе кілька етапів. Перший, на якому відбувається перевірка конкретно вашої окремої фичи і другий, на якому перевіряється все те, що піде в наступний реліз.
Адже навіть зібравши всі в одну гілку (всі фічі) і перевіривши їх локально, не можна бути до кінця впевненим, що в бою, на реальних даних, все запрацює добре. Крім цього, швидше за все, у вас є менеджер або навіть тестувальники, які теж хочуть подивитися / перевірити, чи все гаразд. І тут на сцену вривається ще одна виробниче середовище, яка називається середовищем інтеграції (предпродакшен), або стейджінг (staging), як її всі називають.
Стейджінг - це таке середовище, в якій відбувається перевірка перед боєм. Її особливістю є те, що вона максимально наближена до умов бойової середовища, що дає можливість повніше протестувати то, що відбувається. Зазвичай це те місце, куди йдуть менеджери, тестувальники, замовники. Часто стейджінг виконує відразу два завдання. Як перевірку конкретних фич від розробників, так і остаточний прогін програми перед релізом.
Тут з'являється ще одне нове слово: "реліз". Реліз по-іншому називають "випуск". З одного боку, це процес викочування в бій нової версії системи. З іншого боку, так іноді називають збірку, яка вдає із себе нову версію системи.
Continuous Integration Server
Така система дозволяє дуже сильно прискорити процес інтеграції. Сильно знижується навантаження на розробників і автоматизується рутина. Розробнику досить писати код і відправляти його в репозиторій, а система сама буде проводити необхідні перевірки і виконувати злиття. Безперервна інтеграція є частиною практик під назвою "екстремальне програмування (XP)".
Ми упустили один важливий момент. Яким чином новий код потрапляє в предпродакшен і в продакшен середу після того як ви закінчили розробку? А робить він це завдяки процесу, який в народі називають "Деплой".
Як показує практика, багато хто до цих пір роблять Деплой руками. Заходять на сервер (а якщо їх багато?) Клонують код, руками змінюють базу і так далі.
Можна нескінченно обговорювати те, наскільки це погано. Починаючи з того, що по суті відсутній налагоджений, повторюваний процес, а значить завжди є ймовірність того, що увірветься людський фактор і випадково буде щось забуте / втрачено / видалено. Закінчуючи тим, що знання зберігаються в одній голові, і сам процес релізу стає вуду-процедурою, яку може робити тільки Вася, а іноді він хворіє, ходить у відпустку і може звільнитися. Часто в таких компаніях реліз - вкрай болюча процедура, яка займає не одну годину, а може навіть пару днів.
При добре налагодженому процесі, реліз займає десяток хвилин, і може робитися будь-яким розробником в будь-який момент (майже). Хекслет іноді деплоітся по 5-10 разів в день.
Основні завдання, які стоять перед вами під час деплоя:
- Взяти нову версію коду зі сховищ і залити його на сервер (и)
- Зробити всі необхідні приготування: налити міграції, зібрати frontend-скрипти і т.д.
- Переключити проект на нову версію
- Відкотитися в разі помилок
Поділитися в Фейсбуці