Почему разработчики не должны быть в состоянии развернуть непосредственно в производство? - PullRequest
11 голосов
/ 10 ноября 2010

Я всегда работал в средах, где разработчикам приходилось проходить через процесс работы с Network Operations (ребята с сервера), чтобы развернуть материал от разработки / тестирования до производства.

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

Что у меня так далеко:

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

  • Существует некоторая ответственность, если что-то пойдет не так, и более чем один человек знает, что происходит. Босс: «Сайт просто отключился!», Все остальные в офисе: «Эйб только что развернул, это его вина!»

  • Когда кто-то несет полную ответственность за производственный сервер, менее вероятно, что он сделает что-то глупое.

  • (надеюсь) будет больше информации о возможностях развертывания и отката. Журналы, резервные копии, к которым можно вернуться, автоматические функции ...

Есть ли другие веские причины? Я просто ненормальный?

Ответы [ 8 ]

14 голосов
/ 10 ноября 2010

Немногие, которые приходят на ум (могут совпадать с вашими):

  • Разработчик может настроить что-то, пока оно не заработает. Это не должно быть сделано в производстве. Если этот разработчик будет сбит автобусом на следующий день, никто не узнает систему. Документированный и повторяемый кем-то еще процесс развертывания помогает обеспечить сбор таких бизнес-знаний.
  • Как разработчик, я не хочу такой доступ. Если что-то не получается, это менее вероятно, что это моя вина. Я приду и помогу, ведь мы все в одной команде, но мне нравится знать, что кто-то еще должен был проверить мою работу и согласиться с ней. (То же самое относится и к моим дельта-сценариям БД. Я хочу, чтобы более квалифицированный администратор БД, чья исключительная ответственность перед базой данных, проверяла мою работу. Если все, что они делают, это запускают то, что я им говорю, когда я им говорю, то это по сути не отличается давая мне прямой доступ. Это только медленнее.)
  • Разработчики часто быстро исправляют простые вещи. Мы все знаем, что это часто не так просто, как думал разработчик, и что быстрое исправление либо не исправило, либо сломало что-то еще. Независимо от того, насколько малы изменения / исправления, все равно должен быть процесс обеспечения качества. (Для некоторых магазинов, где время безотказной работы не столь критично, что процесс контроля качества на самом деле может быть производственным, но это редкое исключение. Так не должно быть, с точки зрения пуристов, но, как и во всем, это соотношение риска и прибыли. Если риск низок (так как в случае Производственного сбоя не будет большого штрафа, если он вообще есть), а стоимость QA сравнительно высока, тогда все в порядке.)
  • Нормативные требования. Соответствие требованиям PCI и т. Д. Часто требует четкого разделения задач между заданиями. Это часто неверно истолковывается как «разработчики не могут получить доступ к производству» и рассматривается очень черно-белым. Но это означает, что разработчики должны иметь доступ только к тому, что им нужно для выполнения своей работы. Если вам не нужны производственные данные, и эти данные являются конфиденциальными, у вас их не должно быть.
10 голосов
/ 10 ноября 2010

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

«Я просто внесу небольшое изменение конфигурации в Prod, которое ничего не сломает».

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

В некоторых средах (например, финансы) большие суммы денег (а иногда и закон) также подвержены риску из-за необдуманных или злонамеренных изменений в неконтролируемой производственной среде.

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

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

7 голосов
/ 10 ноября 2010

Безопасность - при наличии одного привратника (с резервной копией) только один человек получает доступ к производственным данным и серверам. Это означает меньше точек доступа.

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

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

7 голосов
/ 10 ноября 2010

Основная причина в том, что разрешение разработчика на развертывание напрямую в производство сокращает процесс обеспечения качества. Что вводит риск. Какие типы управления не нравятся.

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

5 голосов
/ 10 ноября 2010

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

  • Управление изменениями
  • Подотчетность
  • QA
  • Сборка / развертывание одной кнопкой
  • Модульные тесты
  • Стабильность кода - предположим, вы нажимаете, верно, когда кто-то еще только что проверил код?

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

2 голосов
/ 10 ноября 2010

Поскольку необходим ОДИН человек, к которому вы можете обратиться, кто знает, что развернуто на сайте. Если каждый разработчик может развернуть, вы не знаете, кто что развернул, когда кто-то замечает что-то не так.

2 голосов
/ 10 ноября 2010

При непосредственном развертывании в производственной среде велика вероятность того, что контроль качества не проводился (т. Е. Ничего не тестировалось).

0 голосов
/ 03 мая 2016

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

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