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

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

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

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

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

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

Все изменения в базе данных Dev включены, некоторые из которых все еще могут быть "незавершенными".
Иногда разработчики вносили противоречивые изменения (которые не были замечены до выпуска выпуска)
Процесс создания и проверки script (по проверке, я имею в виду, пытаюсь устранить проблемы, такие как проблемы 1 и 2), был трудоемким и ручным процессом.
Когда возникли проблемы с script (например, порядок, в котором выполнялись действия, такие как создание записи, которая основана на записи внешнего ключа, которая находится в script, но еще не запущена), потребовалось время, tweak 'так, чтобы он работал гладко.
Это не идеальный сценарий для непрерывной интеграции.

Итак, решение было: -

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

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

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

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

Ответ 1

Автоматизируйте процесс выпуска по мере возможности.

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

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

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

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

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

Ответ 2

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

Полностью автоматизированная и полная сборка. У нас всегда была ночная "сборка", но мы обнаружили, что существуют разные определения того, что представляет собой сборку. Некоторые считают это компиляцией, обычно люди включают модульные тесты, а иногда и другие вещи. Мы внутренне разъяснили, что наша автоматическая сборка буквально делает все необходимое, чтобы перейти от источника к тому, что мы доставляем клиенту. Чем больше мы автоматизировали различные части, тем лучше процесс, и нам приходится делать это вручную, когда время отпускать (и меньше беспокоится о том, чтобы забыть что-то). Например, наша версия сборки маркирует все с номером ревизии svn, компилирует различные части приложения, выполняемые на нескольких разных языках, запускает модульные тесты, копирует выходы компиляции в соответствующие каталоги для создания нашего установщика, создает фактический установщик, копирует установщик в наша тестовая сеть, запускает установщик на тестовых машинах и проверяет правильность установки новой версии.
Задержка между завершением кода и выпуском. Со временем мы постепенно увеличивали задержку между тем, когда мы заканчиваем кодирование для конкретной версии, и когда этот выпуск доходит до клиентов. Это обеспечивает больше времени для тестеров, чтобы тестировать продукт, который не сильно меняется и производит более стабильные выпуски продукции. Здесь важна ветвь/слияние управления версиями, поэтому команда разработчиков может работать над следующей версией, в то время как тестеры все еще работают над последней версией.
Владелец ветки. После того, как мы разветкили наш код для создания ветки релиза, а затем продолжили работу над trunk для следующей версии, мы назначим одного владельца ветки с ротационным выпуском, который отвечает за проверку всех исправлений, применяемых к ветке. Каждая отдельная регистрация, независимо от размера, должна быть проверена двумя разработчиками.

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

По-прежнему выполняется script, чтобы сгенерировать установщики, когда это будет сделано, но мы устраним это.

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

Ответ 5

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

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

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

Тот же ant script (передающие параметры) используется для каждого env (dev, integration, test, prod).

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

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

Процесс Dev

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

Процесс тестирования

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

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

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

Утвердить выпуск для определенной даты/времени
Обзор плана выпуска/отката
запустите ant с параметром "производственное развертывание"
выполнять задачи БД (если они есть) (также эти сценарии могут быть версии и помечены для производства)
выполнить другие системные изменения/конфиги
сообщить об изменениях

Ответ 6

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

Maven for build, Nexus менеджер локального репозитория
Hudson для непрерывной интеграции, релизов, маркировки SCM и продвижения по службе.
Сонар для показателей качества.
Отслеживание изменений базы данных в схеме разработки db и управление обновлениями до qa и выпуск через DbMaintain и LiquiBase

Ответ 7

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

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

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