Demo: Development workflow using GitLab and OpenProject

Recently, there has been a growing interest in Jira -alternative project management tools that work on a private server (on-premises / self-hosted) or in the cloud, can be connected to git or GitLab /GitHub and are open-source.

One of the tools that meets those requirements is OpenProject – a product we officially represent and provide support, licenses, private hosting and training for.

In this article, I will demonstrate a basic flow that combines both OpenProject and GitLab.

This is a typical, changeable flow. I chose a basic process to illustrate the connection between them.

How it looks like if they work together?

The following diagram demonstrates a basic workflow we use to demonstrate to companies that need our help to define workflows and pipelines.

A basic GitLab – OpenProject integration (click to enlarge)

Explanation of the diagram:

The upper section (in purple) is managed by OpenProject – this is a typical workflow. We used the default one of a Work Package named “Task”:

New –> In Progress –> Developed –> In Testing –> Tested –> Closed 

(OpenProject enables you to change the flow and names of the states)

The yellow part is where the developer works and operates git and GitLab operations (and indirectly also OpenProject and GitLab CI/CD).

The blue area is the actions done from the developer’s IDE (or alternatively from the browser – using GitLab’s WebIDE)

The bottom (in grey) is the CI/CD section, performed by GitLab CI runner (usually automatically, after setting a proper configuration)

Explanation of the process shown in the diagram

1. The group leader creates a Task in OpenProject to fix a bug or develop a feature and assigns it to a developer. The task is now in New status.
2. The developer starts working. He moves the task to In Progress status, then creates a git branch and clones or pulls the repo to his workstation (he can also works direct on the browser using GitLab’s WebIDE).
3. After the feature is developed/the bug is fixed, the developer pushes his work to the GitLab server, which triggers a CI pipeline.
4. If the pipeline succeeds, the developer creates a Merge Request, thus starting a code review.
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, with each change triggering a CI pipeline.
6. When developers finished to develop the task he moves the status to Developed.
7. At last, the Merge Request is merged into the master branch, and again a CI pipeline runs to check the merge result.
8. Now it’s time of the QA tester to make sure everything is OK. He moves the status to In Testing.
9. Some changes may be needed on the master branch, after which the software is marked as a new baseline and the task is marked as Tested (and then Closed by the tester or the group leader after a CD process has finished successfully)

Note: the chart shown here might have many variations. We have presented here something preliminary that can be a basis for changes and improvements.

Summary:

• You can connect OpenProject and GitLab. They can also be integrated to GitLab CI/CD (or other CI tools like Jenkins) for testing, build or deployment automation purposes
• You can also refine the integration and develop automations for specific use cases (for example adding an automatic link in OpenProject’s activities when specifying the Task-ID on the side of GitLab). We may write about this in future (register yourself to our mailing list below to get future updates)