Aptly. Как организовать контроль пакетов из внешних репозиториев и делегировать управление в продуктовые команды

Всем привет! Решил отрепостить и сюда тоже нашу совместную с коллегами из Positive Technologies Сашей Паздниковым и Никитой Драчёвым статью про Aptly: будет полезной тех-лидам от разработки. Оригинал размещён на Хабре по ссылке.

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

Возможны ситуации, когда в состав разрабатываемого продукта могут попадать нежелательные изменения, которые содержатся во внешних зависимостях. Это особенно актуально во время сертификации продукта. Как следствие — затягивание сертификаций, сбои ночных тестов и интеграционного тестирования, поломки on-premise production (производственной среды, расположенной на собственных ресурсах организации) при накатывании хотфикса и прочее. В новой статье мы описали подход, который позволит избежать таких проблем.

DevOps best practices: рекомендации по организации конфигураций в TeamCity

DevOps (Development + Operations)

Принимая участие в разработке нескольких сотен сборочных, деплойных и иных автоматических конфигураций для поддержки процессов разработки ПО, рано или поздно начинаешь находить в них и выделять общие решения, концепцию, архитектуру, схему взаимодействия конфигураций между собой. Предлагаю вам некоторые рекомендации в области разработки конфигураций, подходы и схему организации процессов сборки и тестирования ПО. Эти подходы были успешно опробованы мной и моими коллегами: Александром Паздниковым, Ярославом Акимовым и Алексеем Соловьёвым, для большого числа IT-проектов, на базе системы непрерывной интеграции TeamCity.

Частично вопросы организации процессов сборки и тестирования уже были рассмотрены в статье "TeamCity triggers & dependencies: построение процессов разработки и тестирования". В статье ниже приведена терминология основных понятий, используемых при описании конфигураций, рекомендуемый набор конфигураций для произвольного проекта, а также схема взаимодействия конфигураций для релизных и нерелизных сборок, деплоя, функционального тестирования.