Автоматизация версионирования, выпуска и журнала изменений программного обеспечения с помощью CI/CD конвейеров


Автоматизация версионности, выпуска и журнала изменений программного обеспечения с помощью CI/CD конвейеров

Что такое выпуск программного обеспечения?

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

Что такое версионирование программного обеспечения?

Версионирование программного обеспечения — это процесс нумерации различных релизов конкретной программы для внутреннего использования и обозначения релизов.

Все выпущенные изменения с номером версии записываются в определенном порядке в файл, известный как changelog.

Распространенные методы версионирования

  1. Семантическое версионирование — **это распространенный метод, который состоит из трех групп номеров: Major, Minor и Patch, семантическая версия имеет такую структуру **MAJOR.MINOR.PATCH
    1. PATCH — счетчик исправлений ошибок
    2. MINOR — счетчик функциональных возможностей
    3. MAJOR — счетчик изменений в продукте
  2. ** Дата выпуска — **Номер версии программного обеспечения — это дата выпуска, пример UBUNTU 22.04.
  3. Последовательная нумерация — присваивается уникальный идентификатор, состоящий из одной или нескольких последовательностей цифр или букв, используемый для передачи значимости изменений между релизами. Уровень значимости классифицируется по изменениям по сравнению с предыдущим релизом.

Зачем нужна версионность

Оно позволяет программистам и всем людям знать, когда были сделаны изменения, и отслеживать изменения, внесенные в программное обеспечение. В то же время это позволяет потенциальным клиентам знакомиться с новыми релизами и распознавать обновленные версии.

Как ClickPesa внедряет версионирование, выпуск и журнал изменений программного обеспечения

Поскольку ClickPesa любит автоматизировать наши процессы, чтобы повысить производительность и сгладить ситуацию, устранив человеческие ошибки, мы решили позволить конвейеру управлять процессом версионирования, давайте посмотрим, как нам это удалось.

Для ветки или функции, которые готовы к развертыванию в продакшене, PR будет создан в продакшене и объединен с мастер-веткой, конвейер будет работать с мастер-веткой.

На самом деле мы используем Bitbucket, поэтому конвейер настроен следующим образом

   master:
     - step:
         name: bump version
Войти в полноэкранный режим Выйти из полноэкранного режима

Мы добавили шаг для версии bump, который будет делать следующее

  1. Сначала извлекаем все коммиты объединенной ветки и сохраняем их в переменную bash как

    RELEASE_DETAILS
    
  2. Мы используем gulp, который является пакетом javascript для потокового запуска задач, который позволяет разработчикам автоматизировать многие задачи разработки, поэтому после получения RELEASE_DETAILS мы передали их в Gulpfile, который обрабатывает все задачи.

    - gulp autoversion --t "${RELEASE_DETAILS}"
    
  3. В файле gulpfile.js

    const gulp = require('gulp');
    const runSequence = require('gulp4-run-sequence');
    const jsonModify = require('gulp-json-modify');
    const gap = require('gulp-append-prepend');
    
    gulp.task('autoVersion', async function () { // Run tasks sequentially
     runSequence('upVersion', 'saveVersion', 'updateChangeLog');
    });
    
    gulp.task('upVersion', async function () {
     let ver = require('./package.json').version; //version defined in the package.json file
     console.log('current version: ', ver);
     let splitString = ver.split('.', 3);
    
     let majorVersion = splitString[0].split('"', 1);
     let minorVersion = splitString[1].split('"', 1);
     let patchVersion = splitString[2].split('"', 1);
    
     let patchNumber = Number(patchVersion[0]);
     let minorNumber = Number(minorVersion[0]);
     let majorNumber = Number(majorVersion[0]);
     if (patchNumber < 9) {
       patchNumber++;
       splitString[2] = String(patchNumber);
     } else {
       splitString[2] = String(0);
       if (minorNumber < 9) {
         minorNumber++;
         splitString[1] = String(minorNumber);
       } else {
         splitString[1] = String(0);
         majorNumber++;
         splitString[0] = String(majorNumber);
       }
     }
    
     process.env.VERSION = splitString.join('.');
     console.log(' new version : ', process.env.VERSION);
    });
    gulp.task('saveVersion', async function () { // saving new version number into package.json
     return gulp
       .src(['./package.json'])
       .pipe(
         jsonModify({
           key: 'version',
           value: process.env.VERSION,
         }),
       )
       .pipe(gulp.dest('./'));
    });
    gulp.task('updateChangeLog', async function () { // add changes into changelog file
     let messages = process.argv[4];
     console.log(messages);
     messages = messages.replace('>', '*');
     console.log(messages);
     if (messages != '') {
       gulp
         .src('./changelog.md')
         .pipe(gap.prependText(messages))
         .pipe(gap.prependText(`# v${process.env.VERSION}`))
         .pipe(gulp.dest('./'));
     } else {
       console.log('no commit messages');
     }
    });
    
    

Как мы видим, мы вызываем runSequence, который вызывает три другие задачи upVersion, saveVersion и updateChangeLog.

Как мы видим, наша триггерная задача autoVersion вызывается из конвейера, а внутри нее есть функция runSequence, которая последовательно вызывает три задачи upVersion, saveVersion и updateChangeLog.

Давайте рассмотрим каждую задачу
  1. Начнем с задачи upVersion
    1. Что она делает, это просматривает файл package.json и получает номер версии, зависит от вашего способа версионирования, это может быть семантический или последовательный или другой пользовательский способ, что нужно, вы будете делать свою магию увеличения номера версии и сохранять новое значение в примере выше новый номер версии сохраняется в этом process.env.VERSION
  2. Затем мы собираемся обновить файл Package.json с новым номером версии, который вы можете увидеть в коде выше на этой задаче saveVersion.
  3. Последняя задача — обновление файла updateChangeLog

    1. Помните, мы передали RELEASE_DETAILS на шаге 1, который содержит коммиты ветки, которая объединяется, все детали извлекаются и сохраняются в переменной сообщения, вы можете видеть на шаге выше, где версия и коммит добавляются в файл журнала изменений.
    2. Это файл changelog.md с нашими изменениями версии 0.0.1

    v0.0.1

* 👌 IMPROVE: create PR for each branch from staging to master 
* 🐛 FIX:  Inject winston logger to the providers 
* 🐛 FIX: import statements path 
* 👌 IMPROVE: Add wallet transfer transaction job before the payout 
* 👌 IMPROVE: Use one queue to process different jobs 
* 🐛 FIX: Add EBUREAU_WALLET_PAYOUT_TRANSACTION_QUEUE initialization 
* 📦 NEW: Implement a queue for wallet payouts 
* 👌 IMPROVE: add dependencies for gulp 
* 🐛 FIX: name of step for bump version 
* 🤖 TEST: update changelog file and bump version
Вход в полноэкранный режим Выход из полноэкранного режима

Вот это да! Помните, мы изменили два файла package.json, обновив номер версии, и changelog.md, добавив изменения.

Возвращаясь к процессу конвейера, все файлы изменений будут зафиксированы и размещены в соответствии с установленной вами веткой develop или master.

Оцените статью
Procodings.ru
Добавить комментарий