TFS 2015 (и Octopus): непрерывная интеграция, но немного подождите

Когда запрос на включение завершен, наша система сборки (на основе TFS 2015/Octopus) настроена на сборку и развертывание. Проблема в том, что у нас обычно есть куча запросов на включение в очередь, и утверждение каждого из них запускает сборку и развертывание, с созданием/сохранением ненужных пакетов и получающимися электронными письмами в QA о том, что развертывание готово. Возможно, не критическая проблема, но раздражение, чтобы быть уверенным.

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

В качестве альтернативы, запланированная сборка каждый час, но ТОЛЬКО если что-то изменилось, будет достаточно.
В качестве альтернативы, сборка каждый раз, но Octopus будет развертываться только после небольшого ожидания, это тоже сработает.

Помимо написания моей собственной службы Windows, которая использует REST API TFS для запуска сборок каждые x минут, только если что-то изменилось, я не вижу хорошего решения. Или я подумал о том, чтобы где-нибудь сохранить пакеты сборки и написать службу для отправки их в Octopus, только если новые пакеты не поступят в течение x минут.

У кого-нибудь что-то подобное работает?


tfs octopus-deploy tfs-2015
person mhenry1384    schedule 22.05.2016    source источник
comment
запланированная сборка каждый час, но ТОЛЬКО если что-то изменилось, будет достаточно - это, кажется, разрыв между сборкой vNext и сборками XAML.   -  person DaveShaw    schedule 23.05.2016
comment
Rolling builds были обновлены с опцией Batch, однако Build no more often than every X minutes в настоящее время отсутствует. См. 1-й комментарий в сообщении блога от VSTFS.   -  person Alex M    schedule 23.05.2016

Ответы (2)


arrow_upward
1
arrow_downward

В тех местах, где я реализовал это, я выступал за предоставление командам контроля качества решать, когда (или даже если) развертывать. Обычно я реализую две среды:

  • Интеграция с DEV: здесь развертывается каждая непрерывная сборка. Если развертывание прошло успешно, оно становится доступным для группы контроля качества (электронная почта, качество сборки и т. д.)

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

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

person JamesQMurphy    schedule 28.05.2016
comment
Я думал о том, чтобы сделать что-то подобное. Мне даже не понадобится отдельный сервер DEV. Каждое развертывание настроено для развертывания на новом сайте IIS (названном в соответствии с номером выпуска) на сервере QA. Я мог бы дать QA сценарий, который позволил бы им продвигать сборку. Это просто переключит привязки сайта с pending-blahblah.com на blahblah.com. - person mhenry1384; 30.05.2016
comment
Я также следовал этому подходу в прошлом — наличие двух сред гарантирует, что разработчики могут проверить свою работу после PR, до того, как QA возьмется за нее. - person Jim Burger; 28.10.2016

arrow_upward
0
arrow_downward

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

Чтобы решить вашу проблему, вы можете написать приложение powershell/small, которое использует API Octopus для запроса того, что такое последний выпуск, посмотреть, был ли он развернут в QA, и если нет, развернуть его. Затем вы можете запланировать это с помощью планировщика Windows.

Пример кода с использованием клиентской библиотеки C# (не тестировался):

var project = _repository.Projects.FindByName("MyProject");
var qaEnv = _repository.Environments.FindByName("QA");
var release = _repository.Projects.GetReleases(project).Items.First();
var isDeployed = _repository.Releases.GetDeployments(release).Items.Any(i => i.EnvironmentId == qaEnv.Id); // Only returns the first 30 items, uses paging
if(!isDeployed)
    _repository.Deployments.Create(new DeploymentResource()
    {
        ProjectId = project.Id,
        ReleaseId = release.Id,
        EnvironmentId = qaEnv.Id
    })
person Robert Wagner    schedule 23.05.2016