Какие крутые и интересные вещи вы делаете во время автоматизации сборки?
Мне просто любопытно посмотреть, что другие делают во время автоматизации сборки, помимо обычных задач по компиляции, сборке, запуску тестов и т. Д., Которые могут быть полезными и вдохновляющими для других, чтобы рассмотреть и изучить такие, как:
- Генерация кода документации
- Использование метрик кода для измерения качества сборки и сбоя сборки в случае нарушения установленных метрик.
31 ответ
Запуск исполняемых файлов на http://virustotal.com/ для проверки на вирусы всех основных антивирусных движков.
Не то чтобы мы думали, что наши exe-файлы содержат вирусы, но иногда вы получаете ложный положительный результат, и вы не хотите, чтобы это был клиент, который его обнаружит. 8-)
У нас есть твиттер-аккаунт, поэтому мы можем проверить его статус в любое время из любого места
У нас есть кнопка Staples easy, которую мы подключили, чтобы запустить сборку при нажатии.
Создайте отчет для любого TODO/FIXME и т. Д., Которые могут быть разбросаны по всему коду.
Вот некоторые вещи, которые я сделал, делаю или планирую делать:
- Обновите светофор (используя гаджет X10), чтобы указать состояние сборки (зеленый = хорошо, желтый = здание, красный = к сожалению!).
- Сгенерируйте документацию по коду, затем обновите вики проекта с помощью документации.
- Другие обновления вики проекта, такие как размещение номера текущей версии, предоставление ссылки на скачивание и так далее.
- Развернуть (и при необходимости выполнить откат) тестовый сервер, на котором выполняется ручное тестирование. Обычно я делал это с помощью VMWare, поэтому "развертывание" - это создание нового экземпляра виртуальной машины.
- Автоматически перемещать заявки, ожидающие сборки, в QA для тестирования.
- Создавайте отчеты об ошибках для неудачных тестов, неудачных сборок и предупреждений компилятора.
- Пометьте сборку в управлении версиями (также примените информацию о версии).
- Запланируйте проверку после X или более неудачных сборок в течение Y дней. (например, если три сбоя происходят за одну неделю, нам нужно встретиться, чтобы выяснить, что происходит)
- Запланируйте вечеринку "Пицца и пиво" на недели без ошибок.
- Сыграй громко "ка-чинг!" звучать через систему громкой связи всякий раз, когда известная нам функция приведет к новой продаже. В моей старой компании нашей группе продавцов понравилась эта бесполезная функция:).
Извлеките случайное изображение из failblog.com, чтобы прикрепить его к сообщению "ошибка сборки".
Автоматически продвигайте ваш рабочий процесс.
Мы написали пользовательский плагин для нашего сервера Bamboo CI, который собирает все проблемы JIRA, связанные со сборкой (определенные из комментариев фиксации svn), и проверяет их состояние в JIRA.
Как только сборка завершается успешно (и развертывается приложение на работающем сервере), любая проблема на этапе рабочего процесса "ожидает сборки" автоматически переходит на этап "построен и доступен для тестирования", который инициирует отправку электронного письма на тестер назначен на вопрос.
Это означает, что наши тестировщики получают электронные письма с уведомлением о проблеме не тогда, когда разработчик проверяет код, а когда исправление работает на сервере и тестировщик может что-то с этим сделать.
Развертывание веб-сайтов непосредственно для тестирования серверов развертывания.
Несколько вещей.
- Загрузка pdb на Symbol/Source Server <- неоценима для отладки аварийных дампов winqual
- Запустите тесты на установщиках, развернутых в виртуальных машинах через CC.NET
- Создайте базовую виртуальную машину для тестирования через CC.NET и разверните ее на всех QA
- Возьмите копию этого образа виртуальной машины и с помощью EggPlant выполните автоматическое тестирование пользовательского интерфейса.
Мы применяем цифровую подпись ко всем выпускаемым нами двоичным файлам. Сценарий сборки делает это автоматически.
Подставляет номер версии в заставке SVG и затем отображает его в Inkscape.
У нас есть веб-приложение, мы провели тестирование производительности и добавим валидацию HTML/CSS в тестовые сценарии.
У различных проектов, в которых я участвовал, были большие публичные показы о том, кто в последний раз зарегистрировался и кто сломал сборку. Мы сделали это с помощью Build-o-matic, и я написал Team Piazza, чтобы отобразить ту же информацию для сборок Team City.
Управляемый код:
- Обновите все файлы AssemblyInfo согласованной версией
- Запустите StyleCop и FxCop и убедитесь, что код красив и хорошо себя ведет!
Родной код:
- Запустите путь к исполняемым файлам зависящий от исполняемого файла и убедитесь, что зависимости от времени выполнения отладки не появились - слишком часто
- Используйте manifest.exe для выгрузки файлов манифеста и проверки на наличие отладочных зависимостей - эти вещи распространяются повсюду!
- Генерация привязок Python для кода C++ с использованием SWIG
Для разработки Java мы используем:
- JUnit дополнен Cobertura (Cobertura определяет, в каких частях кода отсутствует тестовое покрытие)
- Find Bugs - инструмент, который ищет код на предмет ошибок и уязвимостей
- Инструмент Hudson (см. Hudson.dev.java.net [я пока не могу размещать гиперссылки!]), Который управляет сборкой и тестированием программного обеспечения. У него есть такая функция, как светофор (выше) AoP - синяя успешная сборка и все модульные тесты пройдены, желтая успешная сборка и некоторые модульные тесты не пройдены, красная сборка не выполнена.
Хадсон также
- Управляет сборкой программного обеспечения через плагины для SVN, Continuus и т. Д.
- Ведение истории всех сборок, что позволяет отображать наши тесты Junit и результаты поиска ошибок на графиках трендов.
- Отправляет электронные письма всем заинтересованным сторонам всякий раз, когда сборка приводит к измененному состоянию (например, синий к желтому, красный к синему)
- Вся информация представлена на простой внутренней веб-странице
Мы проводим анализ бинарной совместимости (используя рефлексию) с нашим последним общедоступным выпуском, чтобы убедиться, что мы не вводим бинарные изменения случайно. Всякий раз, когда нас принуждают к критическим изменениям, мы добавляем конкретный API в список "принятых критических изменений", чтобы следующая сборка могла пропустить это тестирование. Когда пришло время для выпуска, у нас есть полный список API, которые ломаются в новой версии.
Для Java вы также можете использовать Ivy для автоматического захвата любых отсутствующих библиотек. Например, если вы используете Hibernate, вы можете включать или не включать эти библиотеки в свой выпуск.
Помимо управления версиями, подписи, тестирования и т. Д., Которые мы уже упоминали здесь несколько раз, мы также:
- запустить spdisposeCheck для sharepoint-dll's
- запустите sigcheck (из sysinternals), чтобы создать хороший обзор версий и примененных сертификатов
Несколько вещей, которые мы сделали:
- Цифровая подпись всех бывших
- Архив pdbs
- Создавайте установщики, используя WIX
- Создайте полные файлы.iso для программного обеспечения, которое распространяется на CD или DVD
У нас был скрипт сборки, который автоматически помечал сборку и SVN и развертывал приложение на сервере приложений WebSphere.
Я действительно удивлен, что никто не упомянул обновление файлов конфигурации! Мы обновляем наши конфигурационные файлы b в зависимости от среды, которую мы создаем для использования скрипта сборки. Это экономит не менее 20 минут, которые потребуются для замены всех строк подключения и настроек приложения. Другие вещи, которые мы делаем:
Обновить номер версии
Переместить на тестовые серверы
Выполнить анализ кода
Состояние сборки электронной почты
Запустите несколько сценариев базы данных
Как насчет встраивания метки времени сборки в каждое построенное изображение?
<ItemGroup>
<StampFile Include="BuildTimestamp.cs"/>
</ItemGroup>
<Target Name="BuildTimestamp"
Outputs="@(StampFile)">
<Message Text="Building Timestamp..." />
<Touch
AlwaysCreate = "true"
Files="@(StampFile)" />
<WriteLinesToFile
File="@(StampFile)"
Lines='public static class Build { public static string Timestamp = "%(StampFile.CreatedTime)" %3B }'
Overwrite="true"/>
</Target>
Вы можете расширить это, включив имя машины, фазу луны и т. Д.
Мы используем 'checkstyle' ( http://checkstyle.sourceforge.net/anttask.html), чтобы сгенерировать отчет для кода, который может быть вновь зарегистрирован и не проверен (формально) до сборки разработчика. Кроме того, я написал несколько пользовательских задач, которые делают следующее:
- Проверьте свойства соединения с БД и попытайтесь установить фактическое соединение с БД (простой код JDBC) и сообщите о наличии каких-либо проблем с учетными данными пользователя и т. Д.
- Добавьте имя пользователя и метку времени последней сборки в код
- Отправьте уведомление нашему корпоративному IM-клиенту (пользовательский список) со статусом сборки
Есть еще несколько задач, которые относятся к внутренним настройкам среды.
Сброс тестовой базы данных в шаге Пост сборки:
- подготовить набор файлов (используя задачу TemplateFile)
Используйте эти файлы для
- удалить тестовую базу данных
- сделать резервную копию центральной базы данных
- восстановить его на новый тестовый экземпляр БД
- запустить сценарии инициализации sql в тестовой базе данных (используя задачу Sql.Execute)
- преобразовать (используя задачу Xml.XslTransform) файлы данных xml в файлы sql (вставки)
- запустить их на тестовой БД
После этого у нас есть чистый тестовый БД с правильной схемой, все фиксированные данные из центрального БД, а затем некоторые дополнительные тестовые данные.
Было бы лучше, если бы схема и фиксированные данные также были в сопоставимых данных и файлах sql, но это WIP. Центральная БД еще нет, но должна быть в системе контроля версий.
Мы много делаем: с MSBUILD
- Получение источников
- Обновить информацию о сборке с отметкой времени и последним набором изменений в информации о файле и версии
- Компиляция:)
- Запустите тесты с Galio
- Создайте протокол испытаний с отметкой текущего времени и опубликуйте его в IIS
- Создайте Zip-пакеты со всеми необходимыми двоичными файлами
- Публикация Zip-пакетов на SVN
- Отключить файл SLN от TFS
- Удалить все bin/obj файлы
- Опубликовать исходный код в SVN
- Отправить по электронной почте, после сборки или неудачи
- Развертывание приложения с использованием скриптов NANT
У нас есть Nabaztag/tag, показывающий, есть ли какие-либо ошибки на сервере сборки.
Я не прочитал больше половины ответов здесь, но я надеюсь, что некоторые из них являются "новыми":
- Установка и обновление старой версии, чтобы проверить отличия файлов от новой установки (тестирует нашу конфигурацию обновления развертывания)
- Разверните наше основное приложение и внешние системные адаптеры на пользовательский Jboss (включенный в проект / выпуск), запустите его и запустите тестовые наборы SoapUI для проверки сквозной функциональности (также дополнительный тест для нашей автоматизации развертывания)
- Примените дельта-сценарии к предыдущей версии базы данных, а затем проведите структурное сравнение с новой установкой, чтобы во время обновлений создавались новые таблицы, столбцы и т. Д.
- Опубликуйте нашу документацию по выпуску в Confluence (мы в основном запускаем наш полный скрипт выпуска каждую ночь), как предварительный просмотр следующего выпуска из транка
Вот некоторые вещи, которые я обычно имею в непрерывной интеграции:
- вычисление метрик кода и статистики производительности (фиксируется нашей платформой во время выполнения тестов);
- запуск тестов качества кода, которые обеспечивают соблюдение определенных правил разработки (например, именование классов, неизменность, допустимые ссылки);
- обновление онлайн-документации, сгенерированной из кода;
- размещение пакетов установки (WiX & ClickOnce) на сервере развертывания и обновление манифеста, необходимого для автообновлений;
- обновление страницы "Скачать" для наших проектов с открытым исходным кодом;
- уведомление всех заинтересованных сторон о сборке и результатах.
Запуск юнит-тестов и инструментов анализа кода, таких как NDepend, Gandarme. Результаты публикуются CC.Net