Это может быть очень частный случай, но мы решили не создавать отдельное задание для удаления сборок по очень простой причине - хранить все журналы, связанные с конкретным номером сборки, в одном месте.Настройка была следующей:
Продвижение здесь означает, что установочный пакет (RPM) доступен для данного сервера, где автоматическое обновление обрабатывает фактическое обновление пакета.
У нас есть одна основная сборка, которая собирается каждый раз, когда доступен новый коммит.У нас были некоторые тонкие настройки, связанные с тихими временами и т. Д., Но в основном каждый новый заданный набор коммитов приводил к новой сборке.Сборка содержит все релевантное и доступное тестирование, которое еще далеко от завершения и, вероятно, никогда не будет.
Каждый час отдельный шаг продвижения обрабатывает переход от подготовки к производству.Эта сборка запускает отдельную рекламную акцию, которая переносит последнюю принятую сборку от CI до постановки.Существует 30 минутная задержка до того, как сборки были продвинуты CI -> staging, чтобы предотвратить случайные продвижения для последних вторых коммитов.Задержки были достигнуты с помощью некоторых скриптов bash find.Порядок промо-акций следующий: чтобы сборка была доступна в стадии подготовки (как минимум) за один час до перехода в промоушен.
Фактический ответ: Этапы продвижения были выполнены в виде отдельных сборок.Чтобы выполнить реальное продвижение, а не отдельную сборку с отдельным журналом, сборка запускает реальное продвижение в основной сборке, используя curl и вызывая remote HTTP API .Это оставляет релевантную звезду рекламных акций в основном журнале сборки.Используя разные цвета, акции видны одним взглядом.
Чтобы демотировать сборки, я решил создать отдельный шаг продвижения "демотить сборки".Это тогда выдаст фиолетовую звезду как признак того, что сборка неисправна и, таким образом, удалена.Понижение можно получить, открыв правильную сборку в пользовательском интерфейсе и нажав кнопку «Удалить сборку».На этом этапе не было добавлено никакой автоматизации, но, создав отдельный этап тестирования, было бы довольно просто автоматизировать понижение в должности.Мы, однако, еще не зашли так далеко.
Преимущества этого подхода включают
- Сборка удаляется путем доступа к сбойной сборке, а не путем предоставления параметров.Упрощает документирование и позволяет справиться с давлением
- Наличие такой «кнопки паники», доступной для любого, кто нажимает на нее, повышает доверие и ответственность за процесс не только среди разработчиков, но и менеджеров и разработчиков.
- Очень просто обнаружить мертвые сборки, так как журнал доступен помимо других журналов продвижения
- Наличие всех соответствующих вызовов продвижения в одной сборке упрощает дальнейшие сценарии
К острым вещам, которые нам еще предстоит улучшить, относятся автоматизация тестирования на более поздних этапах конвейера сборки, а также подходящий способ понижения сборок после понижения в должности.Например, при производстве дефектная сборка и понижение должны всегда приводить к установке последней хорошей сборки, что оказалось довольно сложно достичь.Производственным дата-центрам редко разрешается быть доступными для этого уровня из центра разработки, где находится система CI.Также остановка и запуск конвейера сборки должны быть автоматизированы, так как в противном случае существует вероятность возврата к ручному состоянию.
Естественно, в духе постоянного улучшения всегда есть что улучшить.Вся установка представляет собой что-то вроде беспорядка в сценариях bash / perl, но, поскольку он сценариев и повторяется, всегда есть возможность улучшать один маленький фрагмент за раз.Самая важная вещь - это автоматизация, поскольку она допускает пошаговые шаги, которые более или менее предотвращают любые ручные шаги.