Проект Guardrails: середовища підготовки
Ця серія коротких статей складається з кількох речей, які я дізнався за останні кілька років роботи над проектами в регіоні, в якому ми (припускаємо, що ви читаєте це з тієї ж частини галузі, що й я 🙂) працювати.
Якщо ви просто випадково натрапили на це, серія охоплює деякі фактори, важливі для проекту :
- Не повинно бути «проекту комітету». «
- Ніхто, крім основної команди розробників, не зможе забезпечити розробку, постановку та виробництво.
- Ніхто не повинен мати можливість писати у виробництво, крім команди розробників (і навіть тоді має бути процес розгортання).
Мені не дуже подобається встановлювати подібні жорсткі та швидкі правила, тому що з часом усе змінюється або через необхідність, або завдяки більшому досвіду. Ось чому я люблю «настанови».
Але на момент написання цієї статті я бачу, що відбуваються саме такі речі.
Середовища забезпечення
За останні кілька років ми досягли значного прогресу в тому, як швидко ми можемо налаштувати наші системи так, щоб усі вони відображали одна одну (або загалом). Це включає в себе наші коробки для розробки, те, як наші локальні машини віддзеркалюють програшування та як промежуток віддзеркалює виробництво.
Забезпечення нового середовища, більш-менш. Катайтеся з ним.
Тобто, якщо це «працює на моїй машині», насправді має бути правдою. Це не виправдання для неможливості відтворити помилку.
І коли це правда, вона, швидше за все, буде правдою на машинах інших, на постановці та виробництві. І це приємно, правда? Я маю на увазі, що ми розгортаємо наші коробки, розгортаємо наші сценарії або робимо те, що ми робимо, і тоді ми маємо необхідні налаштування.
Отже, що означає створення середовищ? Це залежить від середовища, яке ви маєте на увазі.
Як це насправді виглядає?
Якщо ви працюєте в WordPress, а я припускаю, що ви працюєте, якщо ви читаєте це, тоді передбачається, що ви використовуєте як мінімум веб-сервер, базу даних і PHP.
Середовище розробки може виглядати так:
- Apache Nginx, _
- MySQL, який є найпоширенішим,
- Принаймні PHP 5.2.4 (рекомендується PHP 7.1),
- Або щось подібне.
Ви також можете використовувати щось на зразок Laravel Valet або щось на зразок VVV. Все залежить від характеру вашої роботи.
Крім того, залежно від характеру вашого бізнесу, ви можете мати IDE, призначену вам разом із різними конфігураційними файлами для виконання певних правил.
А решта середовищ?
Зазвичай:
- розробка стосується налаштування на вашій локальній машині,
- постановка відноситься до області, в якій ви та зацікавлені сторони можете перевірити,
- а виробництво – це місце, де знаходиться програма.
Але це також виглядає по-різному залежно від того, де ви працюєте, як ваша робота організована тощо. Справа не стільки в тому, як ним користуються, а в тому, що ним користуються.
Постановка
Зазвичай це буде надано на сервері (або групі серверів залежно від розміру проекту), на якому ви можете розгорнути свій останній код для тестування. Він може включати часткову функціональність, тестові дані та лише підмножину інформації з виробництва (якщо ви вирішите отримати цю інформацію, а саме базу даних, із середовища виробництва).
Це дає вам та іншим зацікавленим сторонам можливість переглядати, що виходить і як це функціонуватиме у виробництві, не турбуючись про те, щоб знищити щось важливе.
Код зазвичай розгортається з гілки, зазвичай головної, з вашого сховища Git (якщо це те, що ви використовуєте). А такі інструменти, як DeployBot, CircleCI, Travis CI, GrumPHP, Behat тощо, також використовуються для оцінки якості коду, запуску будь-якого автоматизованого тестування та остаточного розгортання коду.
Зрештою, кожне середовище буде налаштовано таким чином, щоб його можна було швидко віддзеркалювати на локальних машинах, проміжних серверах і робочих серверах. Крім того, має бути легко передавати дані між ними, щоб полегшити роботу з даними.
виробництво
Нарешті, виробництво — це фактично функціонуючий проект; Це означає, що він має сервер, програму та базу даних, які працюють у поєднанні один з одним і використовуються користувачами.
Це також означає, що код знаходиться в стабільному місці. Ймовірно, існують механізми реєстрації, які сповіщатимуть команду розробників про будь-які проблеми. Жодна зміна коду не повинна відбуватися в цьому середовищі без попередньої перевірки якості або постановки.
А процеси на місці?
Гаразд, припустімо, що ви працюєте з традиційним налаштуванням, через відсутність кращого терміну, коли всі ваші розгортання виконуються через S/FTP у робочому (або навіть проміжному) середовищі. Таким чином користувачі можуть витягувати файли, вносити зміни та повертати їх назад.
Це погано.
Це означає, що будь-хто з обліковими даними може увійти, внести зміни та обійти контроль джерела, безперервну інтеграцію, інструменти забезпечення якості тощо, внести будь-які зміни, які вони хочуть.
Це підриває всі запущені процеси. Це не тільки обходить стандартну процедуру (яка, звичайно, існує з певної причини), але в кінцевому підсумку порушує код, який розробник або команда розробників має на своїх машинах, головним чином тому, що те, що знаходиться у виробництві, більше не синхронізується з репозиторій коду.
Крім того, цей код можна розповсюдити між філіями, які ще не об’єднано чи розгорнуто. Це залишає нас перед різноманітними ситуаціями, у яких розробники та клієнти порушили певну частину процесу збирання і, таким чином, весь проект.
Коли приходить час перевірити виробництво, воно не синхронізується з розробкою та постановкою, і ніхто не знає, чому. Коли настає час розгортання, зміни перезаписуються, і відповідальні втрачають те, що вони думали побачити.
Що має робити команда?
Я не знаю, чи є одна правильна відповідь на це питання, але чим довше я працюю в цій галузі, тим більше я вірю, що фірма – або фірми – відповідальні за розробку рішення для клієнта, повинні контролювати процес з кінця. до кінця.
- Дизайнери відповідають за управління своїми сферами створення концепцій, макетів, створення демонстраційних шаблонів і отримання відгуків,
- Менеджери проектів відповідають за комунікацію з відділами,
- Розробники несуть відповідальність за реалізацію рішення та зв’язок роботи дизайнерів із функціональним сервером,
- Клієнт несе відповідальність за перегляд змін, надання відгуків і будь-якої іншої інформації, необхідної для виконання завдання.
Це означає, що коли справа доходить до налаштування домену, хостингу, середовища, контролю версій, процесу збирання та безперервної інтеграції, а також усього іншого, про що я не згадав, безпосередньо лежить на команді розробників.
Залишайтеся в окопах, залишайтеся на меті (але пам’ятайте про оточуючих).
Простіше кажучи, це не є обов’язками клієнта, і ними не повинно бути. Межі відповідальності слід встановити, підтримувати та поважати в усіх командах – не лише у розробників і клієнтів, або клієнтів і дизайнерів, чи дизайнерів і розробників тощо.
Що далі?
У наступній публікації я розповім про обов’язки розробників (та інших зацікавлених сторін) щодо підтримки середовища для коду.
Тобто хто за що має нести відповідальність і хто має доступ читати та записувати які дані та як це може зрештою вплинути на результат проекту.