Усовершенствования процесса выпуска

Question

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

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

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

Мой пример: у предыдущего работодателя все разработчики изменили базу данных в одной общей базе данных разработки. Затем, когда дело дошло до времени выпуска, мы использовали SQL Compare Redgate для генерации огромного сценария из-за различий между базами данных Dev и QA.

Это работает достаточно хорошо, но проблемы с этим подходом являются: -

1. всех изменений в базе данных Dev включены, некоторые из которых все еще может быть «работает в процессе».
2. Иногда разработчики вносили противоречивые изменения (которые не были замечены до тех пор, пока выпуск не был выпущен)
3. Это было трудоемким и ручным процессом для создания и проверки подлинности скрипта (по проверке я имею в виду, пытаюсь устранить такие проблемы, как проблема 1 и 2).
4. Когда возникли проблемы со сценарием (например, порядок, в котором выполнялись действия, такие как создание записи, которая опирается на запись внешнего ключа, которая находится в скрипте, но еще не запущена), потребовалось время, чтобы «настроить» ее так он прошел гладко.
5. Это не идеальный сценарий для непрерывной интеграции.

Таким образом, решение было: -

1. Принудительно политику всех изменений в базу данных должны быть написаны сценарии.
2. Соглашение об именах важно для обеспечения правильного выполнения порядка скриптов.
3. Создайте/используйте инструмент для запуска скриптов во время выпуска.
4. Разработчики имели свою собственную копию базы данных действительно развиваются против (так что больше не было «наступая друг другу на пальцах»)

Следующий релиз после того, как мы начали этот процесс был намного быстрее, с меньшим количеством проблем, на самом деле единственные проблемы были обнаружены из-за того, что люди «нарушали правила», например, не создавали сценарий.

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

Мы применили еще несколько изменений (например, введение CI), но это было самым значительным, в общем, мы сократили время выпуска примерно с 3 часов до максимум 10-15 минут.

Answer 1

Автоматизировать процесс выпуска можно везде, где.

Как и другие намеки, используйте разные уровни построения «глубина». Например, сборка разработчика может сделать все двоичные файлы для запуска вашего продукта на машине dev, непосредственно из репозитория, в то время как сборка установщика может собрать все для установки на новую машину.

Это может включать в себя

• двоичные файлы,
• JAR/WAR архивы,
• файлы конфигурации по умолчанию,
• сценарии установки схемы базы данных,
• сценарии миграции базы данных,
конфигурации
• OS скрипты,
• man/hlp pages,
• HTML документация,
• PDF документация

и так далее. Установщик может собрать все это в инсталляционный пакет (InstallShield, ZIP, RPM или что-то еще) и даже собрать CD ISO для физического распространения.

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

Answer 2

Автоматизированная одноэтапная сборка. Скрипт сборки мусора редактирует все файлы конфигурации установщика, файлы программ, которые нуждаются в изменении (управление версиями), а затем строит. Не требуется вмешательства.

Существует еще сценарий для генерации инсталляторов, когда это будет сделано, но мы устраним это.

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

Answer 3

За прошедший год мы сделали несколько вещей, чтобы улучшить процесс сборки.

1. Полностью автоматизированная и полная сборка. У нас всегда была ночная «сборка», но мы обнаружили, что существуют разные определения того, что представляет собой сборку. Некоторые считают это компиляцией, обычно люди включают модульные тесты, а иногда и другие вещи. Мы внутренне разъяснили, что наша автоматическая сборка буквально делает все необходимое, чтобы перейти от источника к тому, что мы доставляем клиенту. Чем больше мы автоматизировали различные части, тем лучше процесс и меньше мы должны делать вручную, когда пришло время выпускать (и меньше беспокоиться о том, чтобы забыть что-то). Например, наша версия сборки маркирует все с номером ревизии svn, компилирует различные части приложения, выполняемые на нескольких разных языках, запускает модульные тесты, копирует выходы компиляции в соответствующие каталоги для создания нашего установщика, создает фактический установщик, копирует установщик в наша тестовая сеть, запускает установщик на тестовых машинах и проверяет правильность установки новой версии.

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

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

Answer 4

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

1) Установите комплект и один щелчок развертываний UAT

Мы упаковываем наше приложение в качестве установочного комплекта с использованием NSIS (не MSI, которая была намного более сложным и ненужным для наших нужд). Этот установочный комплект сделал все необходимое, например, остановить IIS, скопировать файлы, поместить файлы конфигурации в нужные места, перезапустить IIS и т. Д. Затем мы создали конфигурацию сборки TeamCity, которая дистанционно запускала этот установочный комплект на тестовом сервере, используя psexec.

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

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

2) Автоматизация развертывания баз данных

Развертывание изменений в базе данных была большая проблема, как хорошо.Мы уже обрабатывали все изменения БД, но все еще были проблемы с пониманием того, какие скрипты уже выполнялись и которые все еще нужно запускать и в каком порядке. Мы рассмотрели несколько инструментов для этого, но закончили тем, что стали нашими.

DB-скрипты были организованы в структуре каталогов по номеру выпуска. В дополнение к скриптам разработчикам необходимо было добавить имя файла сценария в текстовый файл, по одному имени файла в строке, в котором указан правильный порядок. Мы написали инструмент командной строки, который обработал этот файл и выполнил сценарии для данного БД. Он также записал, какие сценарии он выполнил (и когда) в специальной таблице в БД, и в следующий раз он не запустил их снова. Это означает, что разработчик может просто добавить сценарий БД, добавить его имя в текстовый файл и запустить инструмент против базы данных UAT, не запускаясь, спрашивая других, какие сценарии они выполняли. Мы использовали тот же инструмент в производстве, но, конечно, он запускался только один раз для выпуска.

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

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

3) Ветвление для выпуска

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

Answer 5

Согласен с предыдущими комментариями.

Вот что развивалось там, где я работаю. Этот текущий процесс устранил «gotchas», который вы описали в своем вопросе.

Мы используем ant, чтобы вытащить код из svn (по версии тега) и втянуть зависимости и построить проект (а иногда и развернуть).

Для каждого env (dev, integration, test, prod) используется такой же скрипт ant (параметры прохождения).

процесс проекта

• Захватив требования, как пользователь «истории» (помогает избежать придирки над интерпретацией требования, когда сформулирована в качестве значимого взаимодействия пользователя с продуктом)
• следующие проворными принципами так что каждая итерация проекта (2 недели) приводит к демонстрации текущей функциональности и освобождаемого, если ограниченного, продукта
• управлять историями выпуска в течение всего проекта, чтобы понять, что находится внутри и вне сферы действия (и не допускать путаницы в последний раз Нут исправления)
• (повтор предыдущего ответа) замораживание кода, то только тест (без дополнительных возможностей)

Dev процесс

• блок тестирует
• код возвраты
• по расписанию автоматические сборки (например, круиз-контроль)
• завершает сборку/развертывание в среде интеграции и пробеги дым тест
• Тег кода и сообщать команды (для тестирования и выпуска планирования)

процесс испытаний

• функциональное тестирование (селен, например)
• выполнения планов испытаний и функциональные сценарии

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

Процесс выпуска

• Утвердить выпуск на определенную дату/время
• план Обзор релиз/Откат
• запустить муравей с «развертывания производства» параметра
• выполнять задачи БД (если они есть) (также эти сценарии могут быть версии и помечены для производства)
• выполнить другие системные изменения/c onfigs
• общаться изменяет

Answer 6

Я не знаю, или практиковать SDLC, но для меня, эти инструменты были незаменимы в достижении гладких релизов:

• Maven для сборки, с Nexus локального менеджера хранилища
• Hudson для непрерывной интеграции, выпускает сборки, маркировку SCM и продвижение по службе
• Сонар для качественных показателей.
• изменение базы данных отслеживания для разработки БД схемы и управления обновлениями для обеспечения качества и выпуск через DbMaintain и LiquiBase

Answer 7

В проекте, в котором я работаю, мы использовали миграции Doctrine (PHP ORM) для обновления и понижения базы данных.У нас были всевозможные проблемы, так как сгенерированные модели больше не соответствовали схеме базы данных, в результате чего миграции полностью не срабатывали наполовину.

В конце концов мы решили написать нашу собственную супер базовую версию того же самого - ничего необычного, просто вверх и вниз, чтобы выполнить SQL. Во всяком случае, это получило отличную (до сих пор - тротуарную древесину). Хотя мы немного изобретали колесо, написав наш собственный, тот факт, что основное внимание уделялось простоту, означало, что у нас гораздо меньше проблем. Теперь релиз - это cinch.

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