Project Guardrails: Writing To Production
У кількох останніх статтях я розповідав про кілька речей (збережених для фактичного написання в виробництві), які допомагають успішно запускати проект:
- Небезпека «проектування комітетом »
- Міркування щодо створення середовища.
Останнє, про що я хотів би розповісти про знання, які я отримав до цього часу, це про збереження прославлених ключів від царства письма до виробництва та про те, чому це важливо.
Написання для виробництва
Ідея написання до виробництва може здатися найбільш догматичною огорожею зі згаданих, оскільки зазвичай це добре для тих, хто розробляє рішення, і вони знають тонкощі того, як воно працює.
Інші зацікавлені сторони, швидше за все, цього не роблять (але якщо вони це роблять і команда розробників погоджується, щоб інші використовували контроль версій для вирішення цієї проблеми, тоді дерзайте).
Хто насправді має дозвіл адмініструвати ці речі?
Однак пам’ятайте, що, як згадувалося раніше в цій серії, спосіб, у який ми розгортаємо наші проекти, зараз змінився, тому ми часто маємо постійне розгортання та постійну інтеграцію.
І часто ці служби підключаються до сховища вихідного коду, такого як GitHub, і системи обміну повідомленнями (яка, у свою чергу, може бути підключена до Slack, що я вважаю корисним).
Щоб люди в команді знали, що було розгорнуто і коли, і вони знали, як отримати код (який з репозиторію, а не завантажуючи його через S/FTP), якщо це необхідно.
Якщо потрібне виправлення, все одно має бути встановлена процедура. Можливо, хтось на виклику, і існує процес, за допомогою якого використовується розгалуження, злиття, тегування та семантичне створення версій.
Незважаючи на це, справа не стільки в тому, як працює процес; це те, що він на місці і що його дотримуються.
Звичайно, ці речі створені не для того, щоб ускладнити розробку (хоча я розумію, як це може здатися). Це навпаки. Це з різних причин:
- щоб підтримувати безперервне розгортання, знаєте, безперервне,
- мати інтегровані тести,
- постійно вимірювати стандарти кодування або якість коду,
- щоб запобігти ковбойському кодуванню,
- і більше.
Йдеться не стільки про те, щоб не допустити інших людей, але якщо це відповідальність розробників за просування коду, то чи повинен хтось інший мати доступ для запису на сервер?
І це суть: якщо ви працюєте в команді, де наявні у вас процеси можуть повністю підірвати роботу, яку ви виконуєте, яка взагалі мета процесу?
Тому що в будь-який момент може прийти хтось інший і це знехтувати всім, що ви зробили. Тоді ви принаймні:
- застрягли з необхідністю вносити свої зміни, ймовірно, через S/FTP,
- порівняти його за допомогою інструменту порівняння з гілкою, над якою хтось працює,
- запровадити зміни (давайте з’ясуємо, чому вони були зроблені),
- а потім поверніться до роботи над вимогами.
Це звучить неспокійно, коли ви так говорите, але це саме те, що відбувається.
Винос
Тож яка ціль останніх кількох дописів? Якби мені довелося підсумувати це якомога стисло, це:
Коли справа доходить до проекту, знайте свої обов’язки та не виходьте за їх межі. Інакше ви ризикуєте зірвати всю справу.
Це стосується розробників, дизайнерів, клієнтів, маркетологів, менеджерів проектів тощо. Як розподіляються ролі, це не має великого значення (я маю на увазі, що зазвичай зрозуміло, хто ким має бути в ролях вище), але я маю на увазі з точки зору хто насправді головна особа – власник проекту – для всього проекту.
Не будь таким.
І залежно від того, як буде відбуватися все вищезазначене, проект може бути відносно простим набором повсякденної роботи.
Наскільки це можливо, ми не хочемо отримувати задоволення від того, що ми робимо