Розробка на виробничому сервері

Сьогодні я закричав на розробку програми на виробничому сервері. Цитата: " Розробка на виробничому сервері неприйнятна - ніколи! "

Ось така ситуація.

1. Я створив екземпляр розробки: http://example.com:3000
2. Виробничим екземпляром є: http://example.com
3. Я завершую всі мої роботи з розробки, http://example.com:3000і коли клієнт задоволений змінами, я переходжу до них http://example.com.

Додаток, з яким я працюю, - це стара програма Ruby on Rails , і я мушу сказати, що спочатку я намагався створити середовище розробки локально, але я ніколи не міг запустити його. Пробуючи деякий час, я здався і вирішив розвиватися на виробничому сервері.

Знову ж, я ідіот? Напевно, так, але я займаюся веб-розробкою вже пару років, і я ніколи не стикався з такою ситуацією. Хто правий і чому?

Раніше я розроблявся на виробничому сервері. Це може спрацювати нормально, але це недоцільно принаймні з двох причин:

1. Код розробки може спричинити нескінченні цикли, витоки пам’яті чи інші проблеми, які блокують процесор, з’їдають всю пам'ять або іншим чином впливають на сервер таким чином, що вплине на ваш виробничий код.
2. Якщо вам потрібно внести зміни до компонентів серверного середовища в рамках вашої роботи з розробки, як-от версія Ruby або MySQL чи будь-що інше, ви будете в змозі.

Як заявили інші, кодування в середовищі PROD піддає користувачам ваші помилки. Навіть якщо ви створили інший екземпляр, у вас все ще є спільні апаратні ресурси та ви все ще можете отримати доступ до виробничих файлів та баз даних. І як зазначають деякі коментарі, якщо ваш екземпляр Dev був зламаний (наприклад, ви забули його витерти, а хтось потім виявив масштабний подвиг безпеки в Rails), тепер у вас з'явилася загальнодоступна машина з дією вашої програми як шлюз в. Що було б ... прикро.

Різні підприємства мають різні відповіді на це, але його можна загалом розбити так:

• Чи відбулося викручування?
• Скільки часу знадобиться для відновлення зміни (я в першу чергу працюю на C ++, тому відкат бінарного файлу може зайняти значно більше часу, ніж у Ruby, особливо коли ви "втратили" старий бінарний файл і вам доведеться перекомпілювати)
• Що ефект зміни (грубе керівництво: загвинчування збережених даних так набагато гірше , чим не зберігання або відображення даних, які , в свою чергу, гірше , чим не показує сторінку на всіх)
• Якби ти поцупив тоді, вийшов із дверей, хтось би знав, що ти робив?
• Чи був інший варіант розгортання, який би перешкоджав / мінімізував / виявляв гвинт перед ударом?

Це дає вам остаточний розрахунок:

• Скільки коштувала б ця цілком запобіжна викрутка?

Це зараз наскільки менше вашої всієї управлінської структури стоїть перед хлопцем, який приймає бюджетні рішення. Звідси кричати.

Якщо ви працюєте на внутрішній сторінці компанії "Про нас" і вводите власне ім'я, щоб бути Л. "Богоподібним" Томасом, що бентежить проблема прізвиська; якщо ви працюєте над критично важливим для покупки додатком, і воно закінчилося випадково налагодженням простого тексту налагодженням даних кредитної картки на домашній сторінці ... проблема з позовом. Між цими крайнощами лежить все - від зарядження, каліцтва продуктивності та всього іншого, що може відігнати клієнтів.

Причина не допускати цього навіть для сторінки "Про нас" полягає в тому, що кодування безпосередньо у виробництві викликає звикання . Ви починаєте, лише роблячи це для неповнолітніх, але з часом це набагато швидше, що вам не доведеться добирати DEV до переробки.

Крім того, розмір бізнесу може мати великий ефект. У команді з двома людьми, коли щось переходить у фіт, ви нахиляєтесь через плече та йдете "Ой, шат, поклади назад". У компанії на 300 осіб ви повинні почати турбуватися про те, чи була це некомпетентність чи злоба, менеджери можуть нести відповідальність за речі, над якими вони не мали контролю тощо.

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

Я намагався створити середовище розвитку локально, але я ніколи не міг його запустити. Пробуючи деякий час, я здався і вирішив розвиватися на виробничому сервері.

Я підтримую заяви щодо розвитку AVOID на виробничому сервері. Ви можете бути виправданим робити в GUN лише в тому випадку, якщо це корекція помилки друку в конфігураційному файлі та наполягає на вашому менеджері.

WHY NOT?- Тому що, це дуже ризиковано і схильно стати звичкою пізніше, що погано наздожене тебе. Тому що фатальні виробничі помилки / збої можуть коштувати вас звільнити з роботи.

Дозвольте мені повторно повторити його, навіть якщо ви попросили зробити виправлення помилок на productionсервері, спочатку зробіть це Staging. або іншими словами перевірити свої зміни, протестуйте їх і знову протестуйте перед тим, як розмістити у виробництві.

Це те, що часто трапляється в місцях, коли культура «роби це швидко і брудно » здається нормою.

Редагувати: Розвивається на виробничому сервері, оскільки окреме середовище НЕ приймається . Будь-які проблеми, спричинені вашою роботою, можуть просто знищити сервер виробництва та вплинути на продуктивність виробничих додатків . Як, наприклад, я пам’ятаю випадок, коли був захисний отвір, коли мій попередній колега намагався використовувати виробничий сервер WinServer 2003 для цілей розробки.

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

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

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

Так, ви можете ввійти в систему, а не показувати їх клієнту, але це робить налагодження набагато менш кумедним, ніж це вже є.

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

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

Не возиться з виробничими даними, що може статися так легко!

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

Для більшості застосунків значення лежать у даних, а не у підпрограмах.

Я завжди намагаюся запитати інших розробників, які процедури стосуються конкретної компанії. Загалом так, завжди слід:

1. Будуйте локально.
2. Пересуньте його до якогось типу коробки, який максимально імітує виробництво, щоб побачити, чи добре там грає.
3. Можливо, надішліть його до QA або сертифікаційного екземпляра, щоб передати клієнту / QA команді для перегляду змін.
4. Натисніть на виробництво.

Ви можете використовувати рецепти Capistrano в парі з GitHub, щоб обробляти всі ці речі для вас. Якщо робити це потрібно вручну кожен раз, воно може швидко старіти.

Інша проблема розробки на prod - це те, що іноді ці речі пропускаються в керуванні джерелом, і майбутній випуск може скасувати зміни, що швидко виправляються.

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

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

У своїй кар’єрі я знайшов лише дві причини зміни коду на виробничих серверах:

1. Помилки або поведінка, які трапляються лише там і не відтворюються в середовищі розвитку. Вони рідкісні, але їх можна дуже дратувати і важко знайти.

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

Обидва найкраще залишати старшим розробникам, які добре знають системи.