GitLab

Содержание:

• Для новых пользователей
  • Создаем ключ SSH для пользователя GitLab
  • Загружаем ключ SSH в GitExtentions
• DevOps
  • Сборка проекта
  • Бизнес процесс в Jira
• Знакомство и установка Jenkins
• Новое руководство ?????
• Ссылки на документацию

Для новых пользователей

В этом разделе указаны советы и некоторые установки, которые помогут Вашей комфортной и стабильной работе в GitLab и возможно здесь будет что-то еще

• В первую очередь настроем свой профиль GitLab:

  • На главной панели (сверху) нажимаем на иконку пользователя, где выбираем "Edit Profile"
  • Указываем свои личные данные
  • Выбираем соответствующий часовой пояс
  • Добавляем ключ SSH для пользователя, выбрав соответствующий раздел в колонке слева
  • Сохраняем изменения, нажимав вниз "Update profile settings"

Создаем ключ SSH для пользователя GitLab

1. Открываем окно cmd (нажмите сочетание клавиш "Win" + R, в открывшемся окне "Выполнить" введите cmd и нажмите клавишу Enter)

   В случае, если cmd не распознает команды, рекомендую запустить окно GIT - например в GitExtention Ctrl + G , и выполнить эти действия там

2. Вводим в строку ssh-keygen
3. Выбираем директорию для ключей (Советую оставить как есть)
4. Вводим пароль пользователя 2 раза
5. В месте куда положили ключ (Если не меняли директорию, то это C:\Users\USERNAME\.ssh) открываем в редакторе файл id_rsa.pub и копируем всё содержимое
6. Открываем страницу GitLab (В нашем случае это https://git-data.ru/) и логинимся от пользователя, для которого создали SSH ключ
7. В настройках пользователя (В правом верхнем углу выпадающий список на иконке пользователя, "Edit profile") где находим "SSH keys"
8. В поле для ключа вставляем содержимое id_rsa.pub и добавляем его "Add key"

Загружаем ключ SSH в GitExtentions

1. На главной панели GitExtentions нажимаем на раздел "Инструменты"
2. Выбираем "Putty"
3. В выпадающем списке выбираем "Генерировать или импортировать ключ"
4. В появившемся окне выбираем "Conversions", где нажимаем на "Import key"
5. В директории загруженных ключей выбираем приватный ключ и загружаем его

Для полного представления что такое GitLab, с его интерфейсом и возможностями Вы можете ознакомится с документацией GitLab

DevOps

Сборка проекта

На схеме отображен алгоритм сборки корневого репозитория Root Repo. В его состав входят несколько зависимых субмодулей (сборка которых должна происходить в определенном порядке), файлы сборки, и Jenkinsfile (в котором задан порядок сборки всего проекта). Очередность сборки проекта в Jenkinsfile учитывает зависимости субмодулей друг от друга, а так же некоторые особенности сборки, такие как DevExpress, без которого не удастся сборка модуля ThirdParty.

Бизнес процесс в Jira

Что бы связать задачу в Jira c GitLab нужно при создании Merge Request добавить в commit message идентификатор задачи ( Например: SHP-53 Добавлены новые шаблоны договоров )

Существует возможность автоматически закрывать задачу в Jira сразу после Merge (перенести задачу в статус ГОТОВО). Для этого нужно в commit message перед идентификатором задачи добавить одно из слов триггеров:

• Closes
• Fixes
• Resolves

В данном случае процесс управляет порядком выполнения задач. Он исключает переход задачи в статус ГОТОВО не пройдя статус CODE REVIEW, в который, в свою очередь возможно попасть только из статуса В РАБОТЕ. При создании задачи сразу следует определить исполнителя, а исполнителю следует изменить статус задачи из ОТКРЫТО --> В РАБОТЕ.

При переносе задачи в другой статус - она автоматически присваивается к переносящему пользователю как к исполнителю.

Статус Declined предназначен для отклоненных задач, таких как Дубликаты (повторяющие уже существующие задачи) или же не нужные предложения. Для того что бы сделать задачу Дубликатной, следует:

1. Открыть повторявшую ( дублирующую ) задачу
2. Выбрать "Добавить ссылку на задачу"
3. В выпадающем списке выбрать "duplicated"/"is duplicated by" соответственно
4. По идентификатору выбрать связанную задачу В результате обе задачи будут иметь взаимные ссылки, а дубликат будет отмечен соответствующим знаком.

Знакомство и установка Jenkins

Надо написать какой-то комментарий к этой статье

CI (Continuous Integration, Непрерывная Интеграция) — это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.

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

Jenkins — программная система с открытым исходным кодом на Java, предназначенная для обеспечения процесса непрерывной интеграции (CI) программного обеспечения. Он является чрезвычайно расширяемой системой из-за внушительной экосистемы разнообразных плагинов. Настройка пайплайна осуществляется в декларативном или императивном стиле на языке Groovy, а сам файл конфигурации (Jenkinsfile) располагается в системе контроля версий вместе с исходным кодом.\

Jenkins Pipeline — набор плагинов, позволяющий определить жизненный цикл сборки и доставки приложения как код. Он представляет собой Groovy-скрипт с использованием Jenkins Pipeline DSL и хранится стандартно в системе контроля версий.

Существует два способа описания пайплайнов — скриптовый и декларативный.

1. Скриптовый

node {
  stage('Example') {
      try {
          sh 'exit 1'
      }
      catch (exc) {
          throw exc
      }
  }
}

2. Декларативный

pipeline {
  agent any
  stages {
      stage("Stage name") {
          steps {}
      }
  }
}

Литература для ознакомления с синтаксисом и шагами

Они оба имеют структуру, но в скриптовом она вольная — достаточно указать, на каком слейве запускаться (node), и стадию сборки (stage), а также написать Groovy-код для запуска атомарных степов.

Декларативный пайплайн определен более жестко, и, соответственно, его структура читается лучше.

Общая схема непрерывной интеграции с Jenkins:

1. Сначала разработчик фиксирует код в хранилище исходного кода. Тем временем сервер Jenkins регулярно проверяет наличие изменений в хранилище.
2. Вскоре после того, как происходит фиксация, сервер Jenkins обнаруживает изменения, произошедшие в репозитории исходного кода. Дженкинс потянет эти изменения и начнет готовить новую сборку.
3. Если сборка не удалась, соответствующая команда будет уведомлена.
4. Если сборка прошла успешно, Jenkins развертывает встроенный тестовый сервер.
5. После тестирования Jenkins генерирует обратную связь и затем уведомляет разработчиков о результатах сборки и тестирования.
6. Он продолжит проверять хранилище исходного кода на предмет изменений, внесенных в исходный код, и весь процесс будет повторяться.

Страница с руководством по установке и настройке Jenkins

Новое руководство ?????

Здесь будет новое руководство Вероятно будут разъяснения по коду Jenkins

Переход к новому руководству его пока нет

Ссылки на документацию

• Jenkins

• GitLab

• Git

• Markdown в GitLab

Возврат к Содержанию | Открыть страницу Home | Руководство по установке и настройке Jenkins