#workflow #continuous-integration #cruisecontrol.net #build-automation #nant
#рабочий процесс #непрерывная интеграция #cruisecontrol.net #автоматизация сборки #nant
Вопрос:
Я публикую частично вопрос, частично бессвязный в надежде, что это вызовет дискуссию, а также ответит на мой вопрос, который, если честно, скорее представляет собой набор требований.
На моем рабочем месте сборки очень трудоемкие. Это связано с тем, что наша команда очень мала, и есть подозрение, что автоматизация неизбежно пойдет не так, потому что у нас в команде недостаточно опыта, чтобы сделать это должным образом. Я считаю это разумным, но ошибочным аргументом. На моей стороне есть менеджер среднего звена, которому, похоже, нравится концепция автоматизации, и он довольно успешно использует множество небольших функций автоматизации.
Что я собираюсь сделать, так это связать своего рода автоматизированную среду сборки с нашей системой выпуска, которая требует от менеджеров создания различной документации. Это требование сертификации TickIT и не подлежит согласованию. То, что я представляю, — это создание (Windows) Рабочий процесс, для которого у нас настроена ИТ-инфраструктура и который знаком всей компании, запрашивает у менеджеров документацию, которая должна быть подтверждена для выполнения сборки и выпуска. Мы не компания-разработчик программного обеспечения, мы компания, которая продает программное обеспечение, поэтому эти функции должны быть представлены на нетехническом уровне.
Итак, вкратце, наш вариант использования будет выглядеть примерно так:
- Менеджер просматривает систему отслеживания задач и разрешает выпуск на основе текущего состояния
- Рабочий процесс запускается после кэширования текущей версии SVN
- Рабочий процесс требует от менеджера проекта ряда PDF-документов и т.д., Которые необходимо встроить в установочный пакет
- Рабочий процесс запускает процесс сборки ранее кэшированной версии SVN в диспетчере интеграции, таком как CruiseControl (я включаю в это все, что делает непрерывная интеграция, включая модульные тесты)
- Завершенные установочные пакеты автоматически устанавливаются на различные виртуальные машины (полный набор поддерживаемых операционных систем и языков), которые становятся доступными для службы контроля качества
- После завершения выхода из QA установочные пакеты будут выпущены в web
Естественно, поскольку ничто никогда не работает должным образом, следует включить возможность «прервать» рабочий процесс и продолжить вручную в любое время, поскольку мы не хотим, чтобы выпуск задерживался из-за глупой машины, которая не может выполнять свою работу, когда немного здравого смысла сработало бы так же хорошо.
Есть ли у кого-нибудь что-нибудь, что можно было бы считать тематическим исследованием такого рода процессов, или какие-либо комментарии о том, насколько простым или сложным это может быть, или даже насколько это уместно?
Комментарии:
1. Вероятно, лучше подходит для programmers.stackexchange.com
2. Вы считаете? Если бы я хотел быть более конкретным, я мог бы озаглавить это «Как мне запрограммировать рабочий процесс Windows на ..» или «Как мне заставить CCNet выполнять …». Я полагаю, что неопределенность моего вопроса способствует этому.
3. Это своего рода проблема, поэтому я не голосовал за закрытие. Как правило, SO больше подходит для конкретных вопросов программирования (с примерами кода)
Ответ №1:
Недавно мы решили именно эту проблему для одного из наших клиентов. Наша реализация включала следующие компоненты (но вы можете достичь того же с помощью различных инструментов в зависимости от вашей организации).
- Рабочий процесс JIRA — организация процесса (и учет показателей производительности), управление утверждениями и отслеживание истории аудита
- Плагин JIRA — запускает сборки развертывания тесты через сервер CI (Hudson Jenkins). Слушатель: отвечает на обновления статуса от Hudson Jenkins
- Плагин Jenkins — для взаимодействия с JIRA
- build-pipeline-плагин — для управления рабочим процессом Jenkins
- сценарии развертывания — организованы Jenkins Groovy
Это звучит сложно, но многие из этих инструментов имеют отличные API для работы, так что вы можете получить стабильное решение в разумные сроки.
Приветствия,
Джефф
Ответ №2:
Проведя некоторое исследование по этому вопросу, я провел последние несколько дней, играя с CruiseControl.NET. Похоже, что он, вероятно, может делать все, что я ищу, благодаря своей расширяемости. Нет никаких препятствий для запуска другого плагина в конце сборки, который выполняет все развертывание и завершение работы. Однако некоторые требования сложны и занимают неопределенное количество времени, поэтому я думаю, что было бы полезно сохранить какое-то состояние, например WWF. Мне придется поэкспериментировать и обсудить это со своими коллегами.
Ответ №3:
Рассмотрите CloudMunch для этого. CloudMunch предоставляет механизм сборки (основанный на Jenkins), поверх которого создается рабочий процесс продвижения, позволяющий управлять рабочим процессом вручную, а также чистую поддержку RBAC для управления тем, что вы просматриваете.
Отказ от ответственности: я работаю в CloudMunch.