Разработка на производственном сервере

Сегодня меня кричали на разработку приложения на рабочем сервере. Цитата: « Разработка на производственном сервере неприемлема - никогда! »

Здесь ситуация.

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, особенно когда вы «потеряли» старый двоичный файл и должны перекомпилировать)
• Что эффект изменения (грубое руководство: завинчивание сохраненных данных так гораздо хуже , чем не хранение или отображения данных, которые , в свою очередь, хуже , чем не показывает страницу на всех)
• Если вы облажались и вышли за дверь, кто-нибудь узнает, что вы сделали?
• Был ли другой вариант развертывания, который бы предотвращал / сводил к минимуму / обнаруживал провал перед ударом?

Это дает вам окончательный расчет:

• Сколько будет стоить этот полностью предотвращаемый провал бизнесу?

Теперь это намного меньше, чем вся ваша структура управления стоит парню, принимающему бюджетные решения. Отсюда и крик.

Если вы работаете над внутренней страницей компании «О нас» и набираете свое собственное имя, чтобы быть L. «Богоподобный» Томас, смущающая проблема прозвища; если вы работаете над критически важным для бизнеса приложением для покупок, и оно в конечном итоге случайно отлаживает текстовые данные кредитной карты на домашней странице ... проблема с иском. Между этими крайностями лежит все: от невыполнения обязательств, снижения производительности и до всего, что может оттолкнуть клиентов.

Причина, по которой это запрещено даже для страницы «О нас», заключается в том, что кодирование непосредственно в производстве вызывает привыкание . Вы начинаете с того, что делаете это только для несовершеннолетних, но со временем гораздо быстрее не нужно начинать с нуля.

Помимо этого, размер бизнеса может иметь большое влияние. В команде из двух человек, когда что-то пойдет не так, вы склоняетесь через плечо и говорите: «Ой, осел, положи обратно». В компании из 300 человек вы должны начать беспокоиться о том, была ли это некомпетентность или злоба, менеджеры могут нести ответственность за вещи, которые они не контролировали, и т. Д.

В конце дня, если вы будете следовать процедуре и облажаться, они проверят, что не так с процедурой. Если вы обойдете процедуру и напортачите, теперь это ваша ответственность, даже если вина немного рассыпается. Хотите ли вы бросить кости на это зависит от вас.

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

Я действительно поддерживаю заявления, чтобы ИЗБЕЖАТЬ разработки на производственном сервере. Вы можете быть оправданы только под GUN, если это исправление опечатки в конфигурационном файле и настаивает ваш менеджер.

WHY NOT?- Потому что в дальнейшем очень рискованно и привычно становиться привычкой , которая вас сильно догонит. Потому что фатальные производственные ошибки / сбои могут стоить вам увольнения с работы.

Позвольте мне повторить это еще раз, хотя, если вы попросили исправить опечатку на productionсервере, сначала сделайте это Staging. или, другими словами, проверьте свои изменения, протестируйте их и снова протестируйте перед запуском в производство.

Это то, что часто происходит в тех местах, где культура «делай это быстро и грязно » кажется нормой.

Изменить: Разработка на производственном сервере, как отдельная среда также не допускается . Любые проблемы, вызванные вашей работой, могут просто привести к выходу из строя рабочего сервера и повлиять на производительность рабочего приложения . Например, я помню случай, когда была дыра в безопасности, когда мой предыдущий сотрудник пытался использовать производственный сервер WinServer 2003 для целей разработки.

Это действительно проблема протокола. Как правило, это не то, что вы хотели бы делать. Вы хотите оставить производственные машины в покое. Они могут содержать конфиденциальные данные, и вы не хотите ставить под угрозу производительность или стабильность рабочих сайтов с помощью непроизводственного готового кода.

Тем не менее, бывают случаи, когда это обычно делается. Если вы находитесь в ситуации, когда вы выкачиваете программное обеспечение с низким трафиком или простые CMS-сайты, это, вероятно, станет меньшей проблемой. Но если вы работаете над чем-либо с конфиденциальными данными или «критически важными для бизнеса» процессами, вам не стоит рисковать размещением кода разработки на одном компьютере.

Еще одна важная причина, по которой не следует разрабатывать непосредственно в рабочей среде, заключается в том, что экземпляр разработки обычно создает и отображает подробные ошибки и трассировки стека. Вы никогда не хотите показывать это пользователю.

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

Добавлено Решение вашей побочной проблемы, связанной с проблемами в вашем экземпляре разработки: я добился большого успеха в развертывании виртуальной машины на основе VirtualBox, которая дублирует нашу производственную среду (за исключением, разумеется, оборудования) с сервером Ubuntu .

Я очень удивлен, что никто еще не упомянул самую важную причину, почему абсолютно запрещено разрабатывать на производственных серверах:

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

Небольшая ошибка в одном месте приводит к гигантским проблемам в других вычислениях, а затем, на следующий день, все данные становятся мусором, и клиент приходит в бешенство. Это намного, намного хуже, чем ошибка в пользовательском интерфейсе или небольшая ошибка тут и там.

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

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

1. Строить локально.
2. Вставьте его в какой-нибудь тип коробки, которая максимально имитирует производство, чтобы увидеть, хорошо ли он там играет.
3. Возможно, отправьте его в QA или экземпляр сертификации, чтобы передать клиенту / команде QA для проверки изменений.
4. Толчок к производству.

Вы можете использовать рецепты Capistrano в паре с GitHub, чтобы обрабатывать все эти вещи для вас. Если вам приходится делать это каждый раз вручную, он может быстро устареть.

Другая проблема при разработке на prod заключается в том, что иногда эти вещи упускаются в управлении исходным кодом, и будущий выпуск может отменить ваши быстрые изменения.

Если вы работаете в публичной компании в США, у вас даже не должно быть доступа к продукту по нормативным причинам. В общем, ни в одной компании разработчик не должен иметь доступ к продукту (для тех, кто указан во всех ответах, а также возможные юридические причины), поэтому ваш менеджер также не прав, предоставив вам права на этот сервер.

Правила, которые используют «всегда» или «никогда», обычно плохо определены. Будут крайние случаи, когда нарушение передовой практики будет оправдано. Гораздо лучший совет будет: «Не трогайте производственные серверы, если у вас нет веских причин»

В своей карьере я нашел только две причины для изменения кода на производственных серверах:

1. Ошибки или поведение, возникающие только там и не воспроизводимые в среде разработки. Они редки, но могут быть очень раздражающими и их трудно найти.

2. Непосредственное исправление критической ошибки, которую вы просто не можете дождаться, чтобы пройти обычную процедуру развертывания, если она занимает более нескольких минут. После того, как это было очищено с руководством. Если вам повезет, у вас должно быть всего несколько таких за всю вашу карьеру.

Оба лучше оставить старшим разработчикам, которые хорошо знают системы.