Инструменты, помогающие управлять процессом продвижения приложений в корпоративной среде

Question

Мне любопытно, как другие управляют продвижением кода от разработки к ТЕСТИРОВАНИЮ и продвижению в рамках предприятия.

Какие инструменты или процессы вы используете для управления "бюрократической волокитой", критериями входа / выхода?

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

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

Идеальным вариантом было бы браузерное приложение...итак, что там снаружи?пожалуйста, покажи мне, что твой googlefu лучше моего.

Answer 1

Трудно найти хороший в Google. Существует множество инструментов для управления проблемами, поэтому я упомяну, что мы используем и что мы хотели бы использовать.

В настоящее время мы используем продукты serena. Они хорошо работали для нас в прошлом. Team Track - это наше управление проблемами, которое управляет жизненным циклом любой проблемы, над которой мы работаем. Диспетчер версий является нашим источником контроля и имеет функцию реализации рекламных групп, таких как DEV TEST And PROD. Мы используем DEV, TSTAGE, TEST, PSTAGE и PROD, чтобы обозначить движение от одного к другому, но это почти то же самое. Два продукта прекрасно интегрируются, так что источник, связанный с проблемами, связан, но у нас нет настройки процесса сборки в этой среде. Это дорого, но хорошо работает.

Мы надеемся не переходить на более распространенную систему, использующую Jira для управления проблемами, Subversion для управления исходными кодами, Fisheye для соединения этих двух компонентов и Cruise Control для управления сборками. Это дешевле, всего несколько тысяч для корпоративного лицензирования и предоставляет все те же функции, но с дополнительным бонусом SVN, который является очень хорошим менеджером версий кода.

Надеюсь, это поможет.

Answer 2

Есть несколько различных сценариев, с которыми я сталкивался на протяжении многих лет:

Разработка -> Тест :Обычно существует дата замораживания кода, которая прекращает работу над новыми функциями и отправляет в тестовую среду код, который был помечен / заархивирован и который будет собран.Затем это копируется на компьютеры, и тесты проходят нормально.Кроме того, это, как правило, наименее детализированный из всех толчков.

Тест->Prod :Для этого требуется незначительное изменение, которое должно привести к остановке производства, что может означать, что страница "отправилась на рыбалку" откроется, или в IIS не будут запущены какие-либо сайты, и код будет скопирован заново.Существуют особые случаи, когда балансировщик нагрузки может действовать как переключатель, чтобы произошло повышение по службе и ни у кого из клиентов не возникло никаких простоев, поскольку те, что находятся на более старом сервере, переместятся после окончания сеанса.

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

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

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

Теперь есть пара случаев, когда это не используется:

"Исправления" или "Горячие патчи" возникали там, где я раньше работал, и в этом случае конкретные файлы копировались в промежуточную и производственную среды сами по себе, поскольку изменение кода должно было быть запущено в производство как можно скорее, поскольку что-то сломалось в производстве или была выполнена какая-то новая вещь, которая должна была быть выполнена за 2 минуты.В этом случае вводимое изменение кода должно было быть рассмотрено и одобрено перед выходом.

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

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

Еще один момент - масштаб выпуска:1) Крошечный - это тот случай, когда одна веб-страница открывается, чтобы пользователь X мог выполнить Y.

2) Маленький - примерно горстка файлов, которые на самом деле не сложны, но и не совсем тривиальны.

3) Средний - когда переход из одной среды в другую требует изменения множества файлов и обычно имеет скрипты для перемещения.

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

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

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