{"id":5559,"date":"2019-08-13T08:48:12","date_gmt":"2019-08-13T06:48:12","guid":{"rendered":"https:\/\/www.almtoolbox.com\/blog\/?p=5559"},"modified":"2020-12-30T10:02:05","modified_gmt":"2020-12-30T08:02:05","slug":"jira-gitlab-ci-cd-integration","status":"publish","type":"post","link":"https:\/\/www.almtoolbox.com\/blog\/jira-gitlab-ci-cd-integration\/","title":{"rendered":"Is it possible to use Jira + GitLab + GitLab CI\/CD?"},"content":{"rendered":"

Recently we witnessed a growing interest in GitLab and especially in its advanced built-in CI\/CD component. To answer that interest, we have written a few papers on that topic and held several meetings (all of them recorded). As a result we were asked a number of questions about GitLab CI\/CD.<\/p>\n

In this post I want to address two of those questions:<\/p>\n

Whether it is possible to integrate Jira with GitLab?<\/p>\n

Whether it is possible to integrate Jira with GitLab CI\/CD?<\/p>\n

The answer is a resolute Yes.<\/b><\/p>\n

\"jira<\/p>\n

We have studied that issue and will show the way to do it.<\/p>\n

The connection is possible both in the self-hosted version (i.e. on-premises on your own data center or in a private cloud hosting) and in the public cloud version (aka “gitlab dot com”). In fact the connection is possible in all GitLab CI\/CD and Jira distribution forms.<\/p>\n

Based on our experience, we recommend building a plan on how you are going to use those features. In particular your development procedures, use of CI\/CD, user training, etc.<\/p>\n

 <\/p>\n

How will it all work together?<\/h3>\n

The following diagram shows the process we have built and often present to companies, which we advise on the development flows and CI\/CD pipelines.<\/p>\n

This process is very basic and is supposed to be modified according to projects\u2019 specific needs, but it already shows all \u201cclassic quartet\u201d (see the link below) steps.<\/p>\n

\"jira<\/a>

A basic flow (click to enlarge)<\/p><\/div>\n

Here is an explanation of this diagram:<\/h3>\n
    \n
  1. The group leader creates an issue in JIRA to fix a bug or develop a feature and assigns it to a developer. The issue is in the \u201cTo Do\u201d status.<\/span><\/li>\n
  2. The developer starts working. He moves the issue to status \u201cDoing\u201d, then creates a branch and clones or pulls the repo to his workstation.<\/span><\/li>\n
  3. After the feature is developed\/the bug is fixed, the developer pushes his work to the GitLab server, which triggers a CI pipeline.<\/span><\/li>\n
  4. If the pipeline succeeds, the developer creates a Merge Request, thus starting a code review.<\/span><\/li>\n
  5. As a result of the code review, the developer may be requested to do a number of changes before the Merge Request is merged,\u00a0 with each change triggering a CI pipeline.<\/span><\/li>\n
  6. At last, the Pull Request is merged into the master branch, and again a CI pipeline runs to check the merge result.<\/span><\/li>\n
  7. Some changes may be needed on the master branch, after which the software is marked as a new baseline and the JIRA issue is marked as \u201cDone\u201d<\/span><\/li>\n
  8. Note that there can be many variations on this flow. E.g., there can be an additional JIRA status, \u201cQA Testing\u201d to which the issue moves when a Pull Request is merged.<\/span><\/li>\n<\/ol>\n

    Summing up (and adding some points we have learned in our tests):<\/h3>\n