Мы не собираем и не тестируем «все подряд». В Bitbucket настроены хуки, которые срабатывают на пуши и пул-реквесты, и уведомляют Jenkins об изменениях.
А вот автоматической раскатки релизов на бою у нас пока нет, но мы готовимся к этому морально и технически))
Сейчас у нас под Jenkins выделено 4 железных сервера. Начинали с одного сервера и добавляли новые по мере необходимости. Это происходит не очень часто, поэтому autoscaling не используется.
Арифметика тут простая. Если ознакомиться с ценами на Teamcity
то становится понятно, что есть ограничение по числу агентов, которые выполняют сборку и тестирование, и по тестовым конфигурациям. Когда стало расти число разработчиков, сервисов и изменений в сервисах задачи на проверку стали выстраиваться в очередь. Сначала мы пошли по пути увеличения числа серверов, агентов и лицензий, но так долго продолжаться не могло. Конфигураций и агентов не хватало, люди стали откладывать автотесты «на потом», а об автоматическом создании конфигураций и запуске проверки по коммиту и речи быть не могло. Сейчас в 15 командах работает 80 бекенд и фронтенд разработчиков, которые вносят изменения в 150 репозиториев. Умножьте все это на feature(s), dev, release(s) и master сборки, прибавьте к автотестам задачи по выпуску релизов и бесплатное решение становится единственным вариантом дальнейшего роста разработки.
На данный момент Heka отвечает нашим требованиям по простоте администрирования, надежности, функциональности и производительности. Для работы с логами мы выбрали Heka прежде всего потому, что он уже успешно работал у нас в системе для доставки событий из сервисов в Graphite.
С Gollum мы не экспериментировали, но как видно из описанного в статье исходного зоопарка набора инструментов, который у нас был, процесс не стоит на месте и мы регулярно пробуем новые технологии. Сейчас рассматриваем Filebeat как вариант для замены Heka.
Kafka мощный инструмент, но его не просто готовить, появляется промежуточный слой, добавляется точка отказа, появляется Zookiper и т.д. Люди регулярно борются с Kafka «из коробки», например, тут Bubuku. Скорее всего, придется бороться и нам, но уже для других целей. У нас основые проблемы возникли с Flume, перестроение кластера останавливало всю систему до полной перезагрузки. Потратив несколько дней, мы поняли, что можно проще, что Kafka не нужен, и наши усилия по налаживанию кластера лучше направить в другое русло. В итоге, получилось проще и дешевле по админским затратам.
Хороший и актуальный для нас вопрос! Сертификацию мы проходим каждый год, приложения в периметре контролируют (фильтруют) наличие карточных данных перед записью в лог, а сами логи мы НЕ пишем в «общий» ELS. Сейчас в работе внедрение поверх выделенного ELS инструмента для ограничения прав доступа на основании настроек в LDAP. Плюс думаем вместо уровня приложений использовать Lua в Heka для маскирования чуствительных данных, которые могут попасть в лог. Ну и конечно, если вдруг такое нам понадобится, то отправку даже очищенных логов из периметра PCI DSS в «общий» ELS мы будем делать только после её успешного прохождении сертификационного аудита.
А вот автоматической раскатки релизов на бою у нас пока нет, но мы готовимся к этому морально и технически))
ценами на Teamcity
то становится понятно, что есть ограничение по числу агентов, которые выполняют сборку и тестирование, и по тестовым конфигурациям. Когда стало расти число разработчиков, сервисов и изменений в сервисах задачи на проверку стали выстраиваться в очередь. Сначала мы пошли по пути увеличения числа серверов, агентов и лицензий, но так долго продолжаться не могло. Конфигураций и агентов не хватало, люди стали откладывать автотесты «на потом», а об автоматическом создании конфигураций и запуске проверки по коммиту и речи быть не могло. Сейчас в 15 командах работает 80 бекенд и фронтенд разработчиков, которые вносят изменения в 150 репозиториев. Умножьте все это на feature(s), dev, release(s) и master сборки, прибавьте к автотестам задачи по выпуску релизов и бесплатное решение становится единственным вариантом дальнейшего роста разработки.
Выбор в пользу ELS был сделан из-за стоимости, нам нужно обрабатывать большие объемы логов.
С Gollum мы не экспериментировали, но как видно из описанного в статье исходного
зоопарканабора инструментов, который у нас был, процесс не стоит на месте и мы регулярно пробуем новые технологии. Сейчас рассматриваем Filebeat как вариант для замены Heka.Kafka мощный инструмент, но его не просто готовить, появляется промежуточный слой, добавляется точка отказа, появляется Zookiper и т.д. Люди регулярно борются с Kafka «из коробки», например, тут Bubuku. Скорее всего, придется бороться и нам, но уже для других целей. У нас основые проблемы возникли с Flume, перестроение кластера останавливало всю систему до полной перезагрузки. Потратив несколько дней, мы поняли, что можно проще, что Kafka не нужен, и наши усилия по налаживанию кластера лучше направить в другое русло. В итоге, получилось проще и дешевле по админским затратам.