97 этюдов для программистов. Опыт ведущих экспертов

Этот код не трогать! Кэл Эванс

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

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

В большинстве случаев, если речь идет о веб-разработке, архитектуру можно разбить на следующие части:

• Локальная разработка и модульное тестирование на машине разработчика

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

• Промежуточный (staging) сервер, где команда контроля качества и пользователи осуществляют приемочное тестирование

• Боевой (production) сервер

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

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

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

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