Ähnlich wie Moscow Atlassian Meetup. «Как мы растили-растили, и наконец вырастили бамбуковую ферму» Стас Дашковский, Engineer, DevOps Tooling, Align Technology.
3. Кратко о Bamboo для тех, кто не знает
• Bamboo – это сервер CI, оркестратор билд-серверов
• К головному серверу подключаются машины, на которых и
выполняются задачи (компиляция, сборка, тесты) - агенты
• Единица сборки – план. План описывает сборку одного продукта (или
его части)
• План состоит из стадий (stages), выполняемых последовательно
• Стадии состоят из работ (jobs), выполняемых внутри стадии
параллельно. Каждая работа – на своем агенте.
• Работа – набор последовательных операций (выкачать исходники,
запустить скрипт, скачать файл и т.п)
4. Общая конфигурация Bamboo
• Используем уже более 4х лет
• Выбрали из-за интеграции с JIRA и Fisheye
• 90+ агентов
• Половина агентов в Калифорнии, половина
в Москве
• Артефакты хранятся прямо на сервере
Bamboo
• База на MySQL
• Используем для сборки, деплоя, запуска
тестов, сбора статистики
• Учимся на своих ошибках
Статистика сборок за III квартал 2015
Упавших (в том числе тесты) 16674
Успешных 25785
Зависло 1178
Активных планов 673
0
10
20
30
40
50
60
70
80
90
100
2012 2013 2014 2015
Количество сборочных агентов
5. Маленькие проблемы большой bamboo
• ssh-proxy – не пролезают большие репозитории (5Gb+)
• Использование собственных скриптов
• Ограниченная функциональность по сборке из веток
• Параметризация внутри сборочных скриптов
• Сложность взаимодействия внутри сборки между работами
• Использование файлов и артефактов, сторонних сервисов ключ-значение
• Ограниченный API
• Лезьте прямо в базу
• Ставьте плагины
7. Не повторяйте наших ошибок
• Большие логи складывать в файлы, а не выводить в консоль
• Использовать менеджмент артефактов на базе отдельных решений
• Управлять фермой агентов при помощи CM-системы (chef, ansible,
etc) даже для небольшой фермы. Иначе они очень быстро выходят
из-под контроля
• Процедуру сборки — в код, и версионировать вместе с кодом
• Права доступа и нотификации назначать через группы
9. Интеграция с JIRA
«Обратный» релиз версии – из билда в JIRA
Разработчик переводит тикет в заданный статус с версией
1.0.0.next_build.
1. Билд успешно прошел, запускаем наш скрипт последним шагом
2. Ищем версию “next build” в JIRA-проекте, например 1.0.0.next_build
3. Переименовываем ее в необходимую (например 1.0.0.2). В тикетах она
тоже переименуется.
4. Если надо, то релизим или архивируем предыдущую (1.0.0.1)
5. Создаем новую версию 1.0.0.next_build
6. Смотрим тикеты, которые были переведены в статус уже после начала
билда, и проставляем им только что созданную версию 1.0.0.next_build
7. Переводим тикеты с версией 1.0.0.2 в заданный статус