к чему должны иметь доступ разработчики?

Question

Я работаю в месте, где мы создаем приложения, которые обрабатывают и хранят конфиденциальные данные. у нас есть 3 среды. Dev, UAT / QA (пользовательское тестирование) и Production

разработчики на моей работе не имеют доступа к UAT или Production и имеют ограниченный доступ к Dev. Все, что мы можем сделать в dev, это подключиться к серверу dev DB. у нас нет доступа к самому серверу разработки. поэтому мы не можем играть с такими вещами, как веб-сервер (iis) на dev. если мы хотим изменений, мы должны пройти формальный процесс подачи рабочих запросов нашим сетевым администраторам (что может занять несколько дней). то же самое происходит, если разработчик запрашивал что-то для проверки в базе данных UAT или PRod. это строгое ограничение доступа действительно разочаровывает, когда мы пытаемся поддерживать наши приложения.

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

это строгие права доступа, это нормально?

Answer 1

Это не «сервер разработки», если разработчики не имеют доступа. Теперь нет ничего необычного в том, чтобы иметь 4 среды: производство, подготовка, тестирование и разработка. (отсортировано по увеличению доступа для разработчиков). Если я игнорирую имена, кажется, что у вас такая же структура, за исключением того, что вам не хватает сервера dev.

Answer 2

Сложно сказать, нормально ли это. Например, я работал в инвестиционных банках, где у них даже больше драконовских процедур, чем те, которые вы описываете. Я также работал для одного IB, у которого не было никаких процедур вообще. Тем не менее, заметно, что первые все еще заняты бизнесом, а последние обанкротились совсем недавно!

Answer 3

Звучит немного жестко для меня.Обычно я ожидал бы полного контроля над сервером Dev, я был бы рад видеть доступ только для чтения на тестовом сервере и, если честно, мне не интересно смотреть на рабочий сервер (с точки зрения разработки).

Конечно, здесь сделаны следующие предположения;

• 3 среды запускаются одинаково
• Изменения, внесенные в prod, каскадно возвращаются в dev с помощью теста
• Любые изменения конфигурации в Dev вносятся разработчикомдля тестирования и в prod

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

Это подтверждает нашу процедуру освобождения так же, как и все остальное.

Итак;до тех пор, пока на что-либо задокументировано Everythiong, вам не нужно иметь доступ ни к чему, кроме Dev, но было бы неплохо иметь приличный уровень контроля над средой dev.

Answer 4

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

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

Answer 5

Это вопрос того, что вы хотите

На работе есть 2 конкурирующих требования:

• Быстрое решение проблем / разработка нового кода.
• Обеспечение утечки конфиденциальных данных.

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

Это бизнес решение.

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

Подвести итог

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

Answer 6

Проверьте Stackify. Мы только что выпустили новый сервис, который дает разработчикам больше видимости для их приложений и производственных серверов. Мы можем предоставить им простой доступ только для чтения к таким файлам, как файлы журнала, файлы конфигурации, средство просмотра событий Windows и т. Д. Мы можем решить описанную проблему. Мы в основном изобрели поддержку DevOps: http://www.stackify.com

Answer 7

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