How is GitLab’s DevOps Product Different?
- Here is the GitLab FLOW process we recommend for DevOps teams to follow while using GitLab capabilities within a concurrent development lifecycle.
- Throughout this course we will cover each of the steps in this process as we move through the Concurrent DevOps lifecycle and let you get hands-on with each step.
- But first, let’s take a closer look at the GitLab workflow.
Step 1- Create an Issue
All changes within GitLab start with an Issue.
Issues can allow you, your team, and your collaborators to share and discuss proposals before, and during, their implementation. However, they can be used for a variety of other purposes, customised to your needs and workflow.
Issues are always associated with a specific project, but if you have multiple projects in a group, you can also view all the issues collectively at the group level.
Common use cases include:
- Discussing the implementation of a new idea
- Tracking tasks and work status
- Accepting feature proposals, questions, support requests, or bug reports
- Elaborating on new code implementations
Step 2- Create a Merge Request
Once you have created an Issue and added your changes and/or additions, you will Create a Merge Request to start the CI/CD Process.
Merge requests allow you to visualise and collaborate on the proposed changes to source code that exist as commits on a given Git branch.
You may hear a merge request referred to as a pull request.
Step 3- Commit Your Changes
Once your Merge Request has been submitted, you will Commit your changes, which will initiate the CI pipeline.
Step 4- CI Pipeline Runs
During this step, the CI pipeline will run and initiate code builds, run automated tests, and deploy the branch to the staging environment.
If there are errors, conflicts, or other issues, the pipeline will fail and will provide the appropriate error message for the failure for you to research the issue.
Step 5- Review Apps
Review apps provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
They allow designers and product managers to see your changes without needing to check out your branch and run your changes in a sandbox environment.
Step 6- Peer Review & Discussion
In this step, you will have peers or stakeholders review your changes in the review app and ensure there are no conflicts or edits that need to be made before your commits are finalise.
Step 7- Approve Changes
Once the peer/stakeholder review is complete, a person with Merge rights/permissions will need to approve your changes.
Step 8- Merge; Issue Closed
Once your merge request is approved, the proposed changes are merged into the Master and your issue is closed.
Step 9- CD Pipeline Runs
The Continuous Delivery(CD) pipeline will deploy the changes to the production environment and your changes will be live in the system.
Step 10- Monitor
During this step, you monitor your apps to ensure the changes are having the desired effect.
Keep in mind- with GitLab, it is easy to roll back a change if there is an issue or if anything surfaces in production that needs further adjusting.
GitLab Workflow Components
Gitlab uses terminology for its components that is a bit different from other systems you may have used. Here is a table showing each of the main GitLab components and what their functionality is known as in other systems you may have previously used.
The core building block where work is organised, managed, tracked and delivered to help the team to collaborate and plan work in the form of issues.
A collection of projects and/or other groups. They are like folders.
An issue is part of a project. It is the fundamental planning object where the team documents the use case in the description, discusses the approach, estimates the size/effort (issue weight), tracks actual time/effort, assigns work, and tracks progress.
Story, Narrative, Ticket Epic
A collection of related issues across different groups and projects to help organise by theme Initiatives, Themes.
The linkage between the issue and the actual code changes. Captures the design, implementation details (code changes), discussions (code reviews), approvals, testing (CI Pipeline), and security scans.
Label Used to tag and track work for a project or group and associate issues with different initiatives
A visual listing of projects and issues useful for teams to manage their backlog of work, prioritise items, and move issues to the team or specific stage in the project.
A sprint or deliverable(s), helping you organise code, issues, and merge requests into a cohesive group
A visual representation of the various epics for the group
WRITTEN AND PUBLISHED BY
Muhammad Hassan Advocate Open Source.