What is GitLab
Gitlab is a complete open source DevOps platform, delivered as a single application, fundamentally changing the way Development, security, and Ops teams collaborate and build software.
GitLab Organization
Groups: Groups are top level organization method. Other programs may introduce it as "Project".
Subgroup: This is known as nested groups or hierarchical groups and allows you to have up to 20 levels of groups.
Issues: They 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.
Issue features: Once one create an issue , he can add participants and communicate with them using Comments. He can also assign participants to the issue to help track who is responsible for what.
Epics: Give you opportunity to manage project , issue etc. much more efficiently . Although it is a Premium feature . You may read about this
How Issue is connected with all GitLab components
GitLab Issue Flow
This is how a a team works with a product starting from a issue:
- Create and discuss a new issue:
Team creates an issue
Team applies "Discussion" label
Team discuss using Comments
- Code creation
Back end team starts work and developer starts writing code
Developer assigns issue to themselves
Developer adds "Working on" label
- Commit and merge request
Developer creates commits
Developer pushes commits to a feature
Developer creates a Merge Request
Backend team changes labels to "Frontend"
- Deploy to staging
Frontend developer starts working on issue
Developer assigns issue to themselves
Developer adds "Working on" label
Team reviews and refines code
Team stages code
Team changes label to "Staging"
After successful implementation team changes label to "Ready"
- Ready
Technical documentation team adds "Docs" label
Marketing team adds "Marketing" label
Technical team remove "Docs" label when done
When done, the marketing team removes "Marketing" label and ads "Production" label
- Deploy and Production
Release team merges MR and deploys feature to production
Release team closes issue
Contribute to GitLab
Link: https://gitlab.com/gitlab-org/gitlab
Git Workflow with GitLab
Code Review-Typically Workflow
*Code review workflow *
- New Merge Request:
Edit files inline on branch
Commit changes : Squash only or One commit per file in GUI
Merge request
Resolve merge conflicts
- Assign & Reviews
Assignments
Changes tab to view differences
Edit inline
Make comments inline
Discussion tab to view comments
- Final Assignment: Assignment feature in GitLab
4.
Final review:
Assignments
Changes tab to view differences
Edit inline
Make comments inline
Discussion tab to view comments
Merge approved: Approval feature in GitLab
Additional tools for code review:
- Wiki: A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.
Wikis are very convenient if you don’t want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.
You can create Wiki pages in the web interface or locally using Git since every Wiki is a separate Git repository.
Web IDE: The Web IDE editor makes it faster and easier to contribute changes to your projects by providing an advanced editor with commit staging.
Snippets : With GitLab Snippets you can store and share bits of code and text with other users.
Read more here
GitLab's CI/CD
Continuous Integration(CI): is practice of merging all the code that is being produced by developers.
Continuous Delivery(CD): This adds that the software can be released to production at any time, often by automatically pushing changes to a staging system.
Continuous Deployment(CD): this goes further and pushes changes to production automatically.
When someone create a pull req , the request triggers a pipeline to build, test and validate new code prior to merging the changes within the repository.
CI works to integrate code provided by your team in a shared repository. CI helps you catch and reduce bugs early in the development cycle.
CD ensures that the delivery of CI validated code to your application . CD moves verified code to your application faster.
so CI to detect bug or error and CD to merge the errorless code to push faster.
How CI/CD Works
Key Ingredients
To use GitLab CI/CD , need to define a pipeline within a YAML called
.gitlab-ci.yml: This is a yaml file and is a pipeline definition file. It specified the stages , jobs, and actions that one want to perform. This works as a brain.
and then install and configure
GitLab Runner: This works as a body and written in Go and run the jobs specified in the YAML file using an API to communicate with Gitlab.
CI/CD Pipeline
Basically the pipeline is the process which is done in stage . So what is stage?
- Stage: This is collection of jobs to be run in parallel. The default stages are Build, Test and Deploy.
Here you can see 4 pipeline stages as Build, Test, Staging, Production
2.
Jobs: these are scripts that perform tasks. The jobs in each stage are executed in parallel. if one job fails, next job does not get executed.
- Environments : This are where we deploy to. These are specified in the jobs within the ci.yml file. ex: Build, Test, Staging, Production
GitLab and Auto DevOps
Auto DevOps gives you a pre defined CI/CD configuration which lets you automatically detect, build, test, deploy and monitor your application. This is automatically enabled but you can disable it on Gitlab.
Example CI/CD pipeline:
Publish your website with GitLab Pages
Top comments (0)