Не трогай это!

(В оригинале - Don't Touch that Code!)

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

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

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

• Разработку и юнит-тестирование на локальной рабочей станции

• Сервер разработки, где осуществляется интеграционное тестирование

• Демо-сервер, где верификаторы и заказчики осуществляют тестирование и проверяют критерии приемки

• Производственный сервер

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

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

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

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

Автор оригинала - Cal Evans