Overall Satisfaction with Gitlab
Gitlab is used by my team and many others in my organization. We use it for its core features as a web-based Git repository. This allows us to track changes in our code and make use of the collaboration features in Gitlab like issues and pull requests. We're also getting started with using the CI and package registry features.
- Merge request management.
- CLI User Experience (UX).
- Continuous Integration (CI).
- Package management.
- User and permissions management.
- Integration with our enterprise authorization tools allows for easily collaborating with other engineers in the company, even if they are not in our team or department. This has helped with knowledge sharing.
- Moving to Gitlab CI has the potential to save costs for us on running our own CI servers. If we make use of the pool of resources provided by the enterprise Gitlab server, we can minimize and possibly eliminate our self-hosted CI server.
I have used many self hosted and SaaS products that provide Git repo hosting. These include:
Comparing Gitlab CI to GitHub Actions specifically in this instance, I do like the way that Gitlab allows for a job to be run without requiring code to be push to the repository. GitHub Actions allows for many options to trigger a job, but I have yet to see a manual trigger.
- GitHub
- Bitbucket
- Azure DevOps
- AWS CodeCommit
- GCP Cloud Source
Comparing Gitlab CI to GitHub Actions specifically in this instance, I do like the way that Gitlab allows for a job to be run without requiring code to be push to the repository. GitHub Actions allows for many options to trigger a job, but I have yet to see a manual trigger.
Do you think GitLab delivers good value for the price?
Not sure
Are you happy with GitLab's feature set?
Yes
Did GitLab live up to sales and marketing promises?
Yes
Did implementation of GitLab go as expected?
I wasn't involved with the implementation phase
Would you buy GitLab again?
Yes
Collaboration and Performance
Merge Requests and Issues are the main GitLab collaboration fearures used by the teams I work with.
The team uses branching to work on new application features and then submits merge requests to bring the code into the main branch of the repository. Most of our repositories have protected main branches so communication around incoming code is a must. The merge request console really let's us focus on the code that's coming in and discus anything that might need closer review. All of this discussion happens right in the application so there's a history of the discourse. Along with that, if anything needs to be changed, devs can make the changes right i the web UI and commit the changes back into the merge request.
With Issues, the developers tie feedback from stakeholders directly to lines of code. This helps them track bugs from open to closure. Assigning someone to an issue is helpful so the team knows who is working on which issue.
The team uses branching to work on new application features and then submits merge requests to bring the code into the main branch of the repository. Most of our repositories have protected main branches so communication around incoming code is a must. The merge request console really let's us focus on the code that's coming in and discus anything that might need closer review. All of this discussion happens right in the application so there's a history of the discourse. Along with that, if anything needs to be changed, devs can make the changes right i the web UI and commit the changes back into the merge request.
With Issues, the developers tie feedback from stakeholders directly to lines of code. This helps them track bugs from open to closure. Assigning someone to an issue is helpful so the team knows who is working on which issue.
The merge request feature is probably the most used part of my team's workflow. Git and Gitlab are great for tracking code changes as it is, but we're benefitting from capturing the conversation as well. Most comments might boil down to "LGTM!" (looks good to me) but longer conversations are easy to follow in the UI.
We're also working to get into automated workflows with Gitlab CI so that our commits trigger the next logical action, like a push to the main branch deploying the latest version of the code. We've automated quite a bit of our continuous delivery but growing into continuous deployment with Gitlab is a goal.
We're also working to get into automated workflows with Gitlab CI so that our commits trigger the next logical action, like a push to the main branch deploying the latest version of the code. We've automated quite a bit of our continuous delivery but growing into continuous deployment with Gitlab is a goal.
At the time I'm writing this, the teams I work with are moving out of CI/CD applications into Gitlab CI for deployments and building docker images. Because we are straddling the transition at the moment, we haven't replaced any tools but I can see our current CI engine being replaced by Gitlab. In addition I can see us using Gitlab's docker image registry for storing images needed by our application.