Продвижение кода: соблюдение правил
Итак, вот наша проблема:
У нас есть небольшая команда разработчиков со своими собственными способами работы - я пытаюсь формализовать процесс, в котором мы должны продвигать наш код в следующем порядке:
Локальная песочница> Dev > UAT > Постановка> Live
Разработчики разрабатывают / тестируют по мере того, как они идут в своей собственной песочнице, Dev - это собственный блок, который мы будем использовать для непрерывной интеграции, UAT - еще один сайт в IIS на блоке dev, который использует нашу базу данных dev. Затем мы продвигаемся к промежуточному этапу, который представляет собой сайт в IIS на панели Live и использует данные в реальном времени (точно так же, как в реальном времени, отсюда и этап). Тогда, наконец, мы продвигаемся, чтобы жить.
Вот несколько моих вопросов:
1.) Кажется ли это лучшей практикой? Если нет, то что нужно сделать по-другому?
2.) Как применить правила к разработчикам? Часто разработчики пропускают шаги, чтобы сэкономить время... это не должно допускаться и было бы замечательно, если бы оно могло быть физически принудительно применено.
3.) Как применить эти правила к бизнес-группе? Бизнес-группа просто хочет, чтобы функции были БЫСТРЫМИ. Мы продвигаем только в определенные дни?
3 ответа
Звучит как хорошая установка для меня... у нас нет, как и области, где я работаю. У нас есть DEV > QA > Продукция.
1) Я не совсем уверен, что такое "лучшая практика", но ваша установка кажется мне очень хорошей практикой. Мое единственное беспокойство было бы в среде Песочницы. Есть ли гарантии, что код разработчика будет ежедневно копироваться? на случай, если их машина сильно сломается? Я бы не хотел потерять хороший код разработчика.
2) У нас есть "координатор релизов", который обеспечивает доступ к Sourcesafe и TFS, а также контролирует доступ к среде QA, поэтому они доступны только в определенные моменты времени.
3) То же самое относится и к бизнес-тестерам, за исключением того, что их полномочия предоставляются менеджерами проектов. У руководителя проекта есть документ, который заполняется по проекту, и указываются команды тестирования.
Мы продвигаем только в определенные дни (каждый четверг). Тем не менее, мы понимаем, что могут быть чрезвычайные ситуации, и мы делали производственные выпуски в выходные дни, когда это необходимо, но эти чрезвычайные ситуации документируются после факта и анализируются, чтобы увидеть, что пошло не так и где мы можем сделать улучшения.
Я бы сказал, пока ваша среда контролируется и документируется, у вас все будет хорошо. Было бы хорошо убедиться, что все резервные копии находятся в области песочницы, и что небольшая группа людей контролирует доступ к другим средам. Я бы также порекомендовал вам хранить хорошую документацию о событиях и событиях в "защищенных" средах, на случай, если что-то пойдет не так, вы можете просмотреть журналы и посмотреть, что могло случиться или кто мог это сделать, необязательно указывать пальцем но чтобы вернуться и сказать "что именно вы загрузили / изменили?" таким образом, мы можем видеть, что, возможно, вызвало проблему.
Удачи тебе,
Скотт уже ответил довольно хорошо, поэтому я не буду повторять его логику. Тот, кого он, кажется, пропустил, был:
Как применить эти правила к бизнес-группе?
Проблема в том, что вы ничего не можете навязать бизнес-группе. Только их менеджеры могут.
То, что вы (как ИТ) можете сделать, это встретиться с менеджерами со стороны бизнеса и провести анализ затрат / выгод.
- В худшем случае ошибка
- Вероятность этой ошибки без надлежащего процесса
- Стоит компании такой баг.
В идеале, ошибка была бы чем-то, что на самом деле произошло в прошлом, а не теоретически:)
Затем сравните это с относительно незначительными (просто сделайте некоторые оценки, возможно, с учетом данных, полученных от бизнес-пользователей) затратами на наличие надлежащего процесса и связанных с ним замедлений.
По сути, вам нужен их бай-ин, чтобы убедить их, что в их интересах не срезать углы.
У нас есть аналогичная установка в моем магазине. Мы реализуем это, используя разные физические машины, которые имеют доступ через пароли и т. Д. Я разрабатываю локально на своем собственном VPC, а затем проверяю код. На этом все, на мой взгляд, заканчивается. Другой человек имеет доступ к блоку разработчика, где он запускает сборки по мере необходимости, у него нет доступа к "живому" окну, другой человек делает это. Этот человек имеет доступ к полям "dev" и "live" - таким образом он может выполнить развертывание в чрезвычайных ситуациях и т. Д. При необходимости. Как только сборка отправлена в dev и протестирована, тогда и только тогда выполняется "живая" сборка.