«Сериализировать» бамбуковые сборки? - PullRequest
6 голосов
/ 26 октября 2011

Мы используем Bamboo v3.1.1 в качестве нашего сервера непрерывной интеграции, и он работает довольно хорошо - большую часть времени.

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

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

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

Кто-нибудь знает, как мы можем это сделать ??Есть ли параметр, чтобы сказать Bamboo «не распараллеливать этот план сборки - просто делайте одну сборку за раз, последовательно»

Обновление:

MyПроцесс сборки в настоящее время состоит из двух этапов:

  • сборка ядра (построение решения VS, обновление тестовой базы данных до последних сценариев)
  • тестирование (NUnit 2.4)

«Базовая сборка» может легко выполняться несколько раз параллельно - никаких проблем там нет.Однако этап «Тестирование» нельзя выполнить более одного раза, поскольку некоторые из этих тестов обращаются к единственной общей базе данных «модульных тестов»;если запущено более 1 этапа «тестирования», они в конечном итоге блокируют друг друга.

Итак, как мне сказать Bamboo, что можно распараллеливать этап «сборки ядра», но для «тестирования», всегда запускайте только один экземпляр за раз, независимо от того, сколько сборок запущено ??

Ответы [ 2 ]

2 голосов
/ 03 ноября 2011

Мой подход заключается в том, чтобы поместить core build в один план, а тестирования в другой план. базовая сборка вызовет план тестирования как дочерний план.

Затем, как только базовая сборка завершится, появится план тестирования .

План core build предположительно может быть настроен для параллельного запуска нескольких экземпляров на многих машинах. План тестирования будет ограничен одним запущенным экземпляром плана.

Мое единственное замешательство в том, что вы сказали:

  • сборка ядра

    (построение решения VS, обновление тестовой базы данных до последних сценариев )

Не вызывает ли обновление тестовой базы данных проблему при выполнении тестирования плана?

2 голосов
/ 31 октября 2011

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

Чтобы ваши сборки работали параллельно, у вас должно быть несколько заданий, запущенных на одном этапе.Если вы возьмете задания, которые не могут быть запущены параллельно, и поместите их в отдельные этапы, они будут выполняться последовательно.Например, если у вас есть:

Test Foo Stage:
    Init Foo Database Job
    Hammer Foo Database Job
    Smash Foo Database Job
Test Baz Stage:
    Init Baz Database Job
    Bamboozle Baz Database Job
    Befuddle Baz Database Job

, тогда Init / Hammer / Smash этапа foo будет работать проблемно параллельно.Тем не менее, вы можете поставить каждый на отдельную стадию:

Test Foo Init Stage:
    Init Foo Database Job
Test Foo Hammer Stage:
    Hammer Foo Database Job
Test Foo Smash Stage:
    Smash Foo Database Job
Test Baz Init Stage:
    Init Baz Database Job
Test Baz Bamboozle Stage:
    Bamboozle Baz Database Job
Test Baz Befuddle Stage:
    Befuddle Baz Database Job

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

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

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

...