В этой серии статей я хотел бы представить и обсудить несколько возможных подходов к разработке программного обеспечения с помощью Intersystems Technologies и GitLab. Я охвачу такие темы, как:
- Git 101.
- Поток Git (процесс разработки)
- Установка GitLab
- Gitlab Workflow
- Непрерывная доставка
- Установка и настройка GitLab
- Gitlab CI/CD
В Предыдущая статья Мы покрывали основы Git, почему понимание высокого уровня концепций GIT важно для современного разработки программного обеспечения и как GIT можно использовать для разработки программного обеспечения. Тем не менее, наше внимание было на реализации часть разработки программного обеспечения, но эта часть представлена:
- Gitlab Workflow — полный процесс жизненного цикла программного обеспечения — от идеи к отзывам пользователей
- Непрерывная доставка — Программный инженерный подход, в котором команды производят программное обеспечение в короткие циклы, гарантируют, что программное обеспечение может быть надежно освобождено в любое время. Он направлен на строительство, тестирование и пропустить программное обеспечение быстрее и чаще и чаще.
Gitlab Workflow —————\ Gitlab Workflow является логической последовательностью возможных действий, которые необходимо предпринять в течение всего жизненного цикла процесса разработки программного обеспечения.
Рабочий процесс GitLab учитывает поток GitLab, который мы обсуждали в предыдущей статье. Вот как это выглядит:
- Идея: каждое новое предложение начинается с идеи.
- Выпуск: самый эффективный способ обсуждения идеи является создание проблемы для этого. Ваша команда и ваши сотрудники могут помочь вам польским и улучшить его в трекере выпуска.
- План: После того, как обсуждение приходит к соглашению, пришло время кодировать. Но во-первых, нам нужно расставить приоритеты и организовать наш рабочий процесс путем назначения вопросов к вехам и совету по выпуску.
- Код: Теперь мы готовы написать наш код, как только у нас все организовано.
- Commit: После того, как мы довольны нашим проектом, мы можем совершить наш код до функциональной ветки с контролем версий. Поток GitLab был подробно объяснен в предыдущей статье.
- Тест: Запустите наши сценарии, используя GitLab CI, для создания и проверки нашего приложения.
- Обзор: После того, как наш сценарий работает, и наши тесты и сборки добиваются успеха, мы готовы получить наш код и утвержден.
- Постановка: Теперь пришло время развернуть наш код в промежуточную среду, чтобы проверить, работает ли все, сколько мы ожидали, или если нам все еще нужно корректировки.
- Производство: когда у нас есть все работает, как следует, пришло время развернуть нашу производственную среду!
- Обратная связь: Теперь пришло время оглянуться назад и проверять, какой этап нашей работы потребности в улучшении.
Опять же, сам процесс не является новым (или уникальным для GitLab для этого значения) и может быть достигнут с другими инструментами выбора.
Давайте обсудим несколько этих этапов и то, что они въездуют. Есть также Документация доступный.
Выпуск и план
Начальные этапы рабочего процесса GitLab сосредоточены на Выпуск — особенность или ошибка или какой-то другой вид семантически отдельных работ.
Выпуск имеет несколько целей, таких как:
- Руководство: проблема имеет срок, назначенный человек, срок срок, потраченные на время и оценки и т. Д. Для того, чтобы помочь отследить с проблемой разрешения.
- Административно: проблема является частью вехового совета, что позволяет нам отслеживать наше программное обеспечение, поскольку он прогрессирует от версии для версии.
- Развитие: проблема имеет обсуждение и обмениваться с ним.
Этап планирования позволяет группировать проблемы по своему приоритету, вехою, канбанскому совету и иметь обзор этого.
Развитие обсуждалось в предыдущей части, просто следуйте за любым желаемым потоком GIT. После того, как мы разработали нашу новую функцию и объединили его на мастер — что происходит дальше?
Непрерывная доставка
Непрерывная доставка — это подход для разработки программного обеспечения, в котором команды производят программное обеспечение в короткие циклы, гарантируя, что программное обеспечение может быть надежно выпущено в любое время. Он направлен на строительство, тестирование и пропустить программное обеспечение быстрее и чаще и чаще. Подход помогает снизить стоимость, время и риск получения изменений, позволяя более инкрементным обновлениям приложениям в производстве. Простой и повторяемый процесс развертывания важен для непрерывной доставки.
Непрерывная поставка в GitLab
В конфигурации непрерывной доставки GitLab определяется на основе каждого репозитория в качестве файла конфигурации YAML.
- Конфигурация непрерывной доставки — это серия подряд Этапы Отказ
- Каждый этап имеет один или несколько Скрипты которые выполняются параллельно.
Сценарий определяет одно действие и какие условия должны быть выполнены для его выполнения:
- Что делать (запустить команду OS, запустить контейнер)?
- Когда запустить скрипт:
- Что это запускает (обязывает определенную ветку)?
- Надеем ли мы, если предыдущие этапы не удалось?
- Запустить вручную или автоматически?
- В какой среде, чтобы запустить скрипт?
- Какие артефакты для сохранения после выполнения скриптов (они загружены из окружающей среды в GitLab для облегчения доступа)?
Окружающая среда — Настроенный сервер или контейнер, в котором вы можете запустить скрипты.
Бегуны Выполнить скрипты в определенных средах. Они подключены к вашему GitLab и выполняют скрипты по мере необходимости.
Бегун может быть развернут на сервере, контейнере или даже на вашем локальном компьютере.
Как происходит постоянная доставка?
- Новый коммит подталкивается в репозиторий.
- GitLab проверяет постоянную конфигурацию доставки.
- Конфигурация непрерывной доставки содержит все возможные сценарии для всех случаев, поэтому они отфильтровываются в набор сценариев, которые должны быть запускаться для этого конкретного коммитария (например, фиксирую для мастер-ветви триггеров только действий, связанных с главным отделением). Этот набор называется трубопровод Отказ
- Трубопровод выполнен в целевой среде, результаты выполнения сохраняются и отображаются в GitLab.
Например, вот один трубопровод, выполненный после коммитирования главной ветви:
Он состоит из четырех этапов, выполненных последовательно
- Загрузка нагрузки нагрузки на сервер
- Испытательная сцена управляет модульными тестами
- Стадия пакета состоит из двух сценариев, проводимых параллельно:
- Построить клиента
- Код Export Server (в основном для информационных целей)
- Развертывание этапа движется построенным клиентом в каталог веб-сервера.
Как видно, каждый скрипт успешно работает, если один из скриптов не удался по умолчанию, по умолчанию спустя скрипты не будут запущены (но мы можем изменить это поведение):
Если мы открываем сценарий, мы сможем увидеть журнал и определить, почему он не удался:
Running with gitlab-runner 10.4.0 (857480b6) on test runner (ab34a8c5) Using Shell executor... Running on gitlab-test... Fetching changes... Removing diff.xml Removing full.xml Removing index.html Removing tests.html HEAD is now at a5bf3e8 Merge branch '4-versiya-1-0' into 'master' From http://gitlab.eduard.win/test/testProject * [new branch] 5-versiya-1-1 -> origin/5-versiya-1-1 a5bf3e8..442a4db master -> origin/master d28295a..42a10aa preprod -> origin/preprod 3ac4b21..7edf7f4 prod -> origin/prod Checking out 442a4db1 as master... Skipping Git submodules setup $ csession ensemble "##class(isc.git.GitLab).loadDiff()" [2018-03-06 13:58:19.188] Importing dir /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/ [2018-03-06 13:58:19.188] Loading diff between a5bf3e8596d842c5cc3da7819409ed81e62c31e3 and 442a4db170aa58f2129e5889a4bb79261aa0cad0 [2018-03-06 13:58:19.192] Variable modified var=$lb("MyApp/Info.cls") Load started on 03/06/2018 13:58:19 Loading file /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/MyApp/Info.cls as udl Load finished successfully. [2018-03-06 13:58:19.241] Variable items var="MyApp.Info.cls" var("MyApp.Info.cls")="" Compilation started on 03/06/2018 13:58:19 with qualifiers 'cuk /checkuptodate=expandedonly' Compiling class MyApp.Info Compiling routine MyApp.Info.1 ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1] TEXT: quit, "1.0" } Detected 1 errors during compilation in 0.010s. [2018-03-06 13:58:19.252] ERROR #5475: Error compiling routine: MyApp.Info.1. Errors: ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1] > ERROR #5030: An error occurred while compiling class 'MyApp.Info' ERROR: Job failed: exit status 1
Ошибка компиляции вызвала неудачу нашего сценария.
Заключение
- GitLab поддерживает все основные этапы разработки программного обеспечения.
- Непрерывная доставка может помочь вам автоматизировать задачи построения, тестирования и развертывания вашего программного обеспечения.
Ссылки
- Часть I: Портить
- Введение в рабочий процесс GitLab
- Gitlab CI/CD Документация
- Поток gitlab
- Код для этой статьи
Что дальше?
В следующей статье мы:
- Установите GitLab.
- Подключите его к нескольким средам с установленными продуктами InterSystems.
- Напишите конфигурацию непрерывной доставки.
Давайте обсудим, как наша постоянная доставка должна работать.
Прежде всего, нам нужна несколько сред и ветви, которые соответствуют им. Код переходит в эту ветку и доставляется в целевую среду:
мастер | Автоматический | Тестовое задание | Владельцы разработчиков | Владельцы разработчиков |
преподобный | Автоматический | Преподобный | Владельцы | Никто |
продлицо | Полуавтомат (нажмите кнопку для доставки) | Продлицо | Никто |
Владельцы
|
И, в качестве примера, мы разработаем одну новую функцию с помощью потока GitLab и доставить его с помощью CD GitLab.
- Функция разработана в филиале функции.
- Функциональная филиала рассмотрена и объединяется в главную ветку.
- Через некоторое время (несколько функций объединены) Master объединяется в Prerod
- Через некоторое время (пользовательское тестирование и т. Д.) Предправляется в Prod
Вот как это будет выглядеть так:
- Разработка и тестирование
- Разработчик совершает код для новой функции в отдельный филиал объекта
- После того, как функция становится стабильной, разработчик объединяет нашу функцию филиала в главную ветку
- Код из главной ветки доставляется в тестовую среду, где она загружается и проверена
- Доставка в среду препровода
- Разработчик создает запрос слияния от главной отрасли в филиал Препропрода
- Владелец репозитория через некоторое время одобряет запрос слияния
- Код из филиала Prerod доставляется в среду препровода
- Доставка в среднюю среду
- Разработчик создает запрос слияния от филиала Prerod в ветви PROD
- Владелец репозитория через некоторое время одобряет запрос слияния
- Владелец репозитория нажимает кнопку «Развернуть»
- Код из PROD ветви доставляется в среду PROD
Или то же самое, но в графической форме:
Оригинал: «https://dev.to/intersystems/continuous-delivery-of-your-intersystems-solution-using-gitlab-part-ii-gitlab-workflow-4in1»