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

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

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

Версии обложки компакт-диска создаются вручную; это тоже нужно исправить.

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

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

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

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

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

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

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

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

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

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

Процесс разработки

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

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

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

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

Процесс релиза

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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