Использование рабочего процесса для доставки многокомпонентного / прикладного конвейера

При построении конвейеров непрерывной доставки команды часто сталкиваются с проблемой фан-ин.

Фон

Что мы подразумеваем под этим? Диаграмма ниже показывает типичный сценарий. У вас есть несколько компонентов или приложений, которые являются частью системы. Каждый имеет свой собственный конвейер сборки / тестирования. Это также может быть связано с выполнением развертываний и выполнением различных тестов на уровне компонентов.

В идеале, ваши принципы архитектуры привели к слабосвязанным компонентам с четко определенными интерфейсами. У вас будет подход, обеспечивающий обратную совместимость интерфейса, или, если вам необходимо внести критические изменения, механизм для создания версий вашего API и поддержки одновременных версий. Это позволит каждому компоненту иметь собственный независимый жизненный цикл, включая производственные развертывания.

Однако иногда это невозможно, и вам необходимо собрать (собрать, если хотите) набор компонентов с определенными версиями и выполнить некоторую форму фазы совокупного / интегрированного тестирования. В одном конкретном взаимодействии с клиентом требовалось постоянно запускать комплект нефункциональных тестов для базового набора компонентов. По мере их обновления базовый уровень необходимо было обновлять, и тесты перезапускались. Работая над этой проблемой, мы разработали реализацию для этого общего шаблона Fan-In. В оставшейся части этой статьи я покажу вам, как создать набор заданий для реализации этого шаблона.

Требования адресованы

• Каждый компонент уже имеет собственный конвейер CI / CD, что приводит к публикации протестированных и версионных артефактов.
• Каждый компонент имеет свою собственную стратегию нумерации версий.
• Общесистемный цикл испытаний займет много часов.
• По завершении цикла испытаний его следует запустить снова.
• В начале каждого теста должны быть развернуты все новые версии компонентов.
• Каждый прогон теста должен иметь аудит версий компонентов, обновленных и включенных в тесты.

Внедрение 

Решение реализует требования, используя два задания рабочего процесса:

1. Добавить / объединить манифест вакансии.
2. Развернуть и проверить работу.

Они показаны на диаграмме ниже, с ключевыми шагами, которые они реализуют:

Почему два рабочих места?

Простой ответ «из-за параллелизма». 

Более подробный ответ: 

• Мы хотим, чтобы все триггеры от вышестоящих компонентов были обработаны — мы не хотим отбрасывать ни один из них.
• Мы должны убедиться, что обновления обрабатываются последовательно.
• Мы должны убедиться, что в манифесте происходит только одно обновление за раз (т.е. синхронизированные записи) — т.е. создать параллелизм 1.
• Нам также необходимо убедиться, что только одна сборка может выполнять либо тест развертывания, либо тест NFT, то есть мы не можем начать повторное развертывание новых версий компонентов во время выполнения NFT.

Мы рассмотрели вопрос о том, будет ли достаточно одного задания рабочего процесса, но ограничение параллелизма рабочего процесса означает, что несколько сборок становятся объединенными, поэтому существует риск отбрасывания некоторых триггеров и связанных с ними параметров, а во-вторых, невозможно обернуть более одного этап в параллельную единицу (хорошо теперь по крайней мере, пока JENKINS-29892 не  будет осуществлен).

Добавить / объединить манифест

Давайте начнем с реализации задания Add / Merge Manifest — это тип задания Workflow.

Первая проблема, которую нам необходимо решить, — это где сохранить состояние требуемых версий компонентов, которые необходимо развернуть, то есть манифеста уровня системы или приложения. Был рассмотрен ряд вариантов:

1. Хранение версий в файле в SCM.
2. Хранение версий в общей файловой системе.
3. Хранение версий в файле, связанном со сборкой.
4. Взгляд из внешнего хранилища — то есть всегда беру последние «опубликованные» версии.

Мы приняли решение сохранить версии в файле, связанном со сборкой, поскольку это обеспечивает наибольшую переносимость (полагаясь только на самого Дженкинса, а не на внешние системы), но также и на то, чтобы поддерживать историю.

Наша реализация извлекает предыдущий манифест (т.е. из последней успешной сборки), а затем позволяет вносить обновления / дополнения до того, как он будет повторно опубликован как часть сборки.

Давайте посмотрим, как мы реализуем шаги обработки файлов в рабочем процессе.

Получение предыдущего Манифеста:

try {
        step 'CopyArtifact', filter: 'manifest', projectName:env.JOB_NAME, selector: [$class: 'StatusBuildSelector', stable: false]])
        // Do something with the file
    } catch (Exception e) {
        echo e.toString()
        // Do something to create the first version of the file
}

archive 'manifest'

versions = new Properties()

def str = readFile 'manifest': file, charset : 'utf-8'
def sr = new StringReader(str)
def props = new Properties()
props.load(sr)

writeFile file: 'manifest', text: writeProperties(props)

@NonCPS def writeProperties (props) {
    def sw = new StringWriter()
    props.store(sw, null)
    return sw.toString()
}

versions[app]=revision

build job: downstreamJob, propagate: false, wait: false

def compareVersions ( requiredVersions, currentVersions) {
    currentapps = currentVersions.stringPropertyNames().toArray()
    reqapps = requiredVersions.stringPropertyNames().toArray()
    Properties updatedVersions = new Properties()

    for (i=0; i < reqapps.size(); i++) {
        def app=reqapps[i]
        if (currentVersions.getProperty(app) == requiredVersions.getProperty(app) ) {
            log "Calculating Deltas", "Correct version of $app already deployed"
        } else {
            log "Calculating Deltas", "Adding $app for deployment"
            updatedVersions.setProperty(app, requiredVersions.getProperty(app))
        }
    }
    return updatedVersions
}

if (appsToUpdate.size()>0) {
    log "Update Apps", "The following apps require updating: ${appsToUpdate.toString()}"
    def branches = [:]
    for (i=0; i < appsToUpdate.size(); i++) {
        def app=appsToUpdate[i]
        def revision = updatedVersions.getProperty(app)
        branches[app] = {
            decom(app, revision)
            deploy (app, revision)
        }
    }
    parallel branches
}