Изменение кода на рабочем сервере - это зло. Но как лучше всего справиться с этим, если вы это сделаете?

Question

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

Для всех вас, которые время от времени уходят на темную сторону: как вы пытаетесь устранить недостатки? Вы устанавливаете сервер SVN (...) для отслеживания изменений на компьютерах? Установить задание, которое сравнивает контрольные суммы файлов и рассылает «Помните, что вы изменили это»? Просто разместить записку на доске? Синхронизировать изменения обратно с сервером разработки?

Добавлено: Я воспринимаю это как факт, что такая плохая практика случается. Я не заинтересован в идеальном рабочем процессе, чтобы избежать этого. Или случается ли это чаще в проектах PHP, JAVA или COBOL. Или в небольших и больших проектах. В проектах новичков против ветеранов. Или если вас немедленно накажет космическая сущность, если вы это сделаете. Меня просто интересуют креативные полезные советы от людей, которые знают, как справиться с такой ситуацией.

Answer 1

Имейте план отката на случай, если быстрое исправление не работает.

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

Зачастую это требует наличия сценария базы данных для отмены изменений, внесенных в сценарии базы данных.

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

Answer 2

Не делайте ...... внесите изменения в систему управления версиями, разверните ее в своей среде System Test / UAT, протестируйте изменения, а затем разверните в Production.

В противном случае, как вы узнали, что ваше «исправление» сработало?

Answer 3

Ковбой Кодирование: http://www.bnj.com/cowboy-coding-pink-sombrero/

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

Answer 4

Использовать систему контроля версий и, в этом случае, иметь «стабильную» ветвь (или использовать транк в качестве стабильного компонента). Поставьте там требование, чтобы все в этой ветви (или транке) было подходящим для немедленного развертывания в любой момент времени. И добавьте предупреждение о том, что тот, кто сломает эту ветку / ствол, умрет или каким-либо другим мучительным наказанием.

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

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

Answer 5

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

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

И, конечно, я сделал резервные копии рабочего кода, прежде чем скопировать изменение из разработки.

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