My basic use case for Gitlab was the ticket management, the wiki, the CI/CD pipeline, and the code repository. These four use cases form my core usage.
The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.
Use our online form to submit your review. It's quick and you can post anonymously.
My basic use case for Gitlab was the ticket management, the wiki, the CI/CD pipeline, and the code repository. These four use cases form my core usage.
Gitlab is a developer tool, and it was easy to use. I never had to go to Jira or any project or product management tool. The wiki was there, so the onboarding of my developer was super fast.
Having everything in a single place in GitLab means I do not have to go to any other tool while I am working on GitLab. That was the major advantage.
The ticket management was the part that I was using in GitLab.
Since I was a solo developer, I never used Integrated Code Review in GitLab extensively. However, for teams, it is really useful.
Integrated Code Review is definitely an important feature in GitLab because as soon as the code is committed in a branch, the deployment is a major aspect. Making sure that the build is working fine, testing it, and having it deployed is critical, and GitLab provides a good feature in that area.
I have not heavily used the security scanning part of GitLab.
The ticket management and wiki part I mentioned earlier was what I was using with one of my team members in GitLab.
Since GitLab [Private Offer Only] the main part is the Git part. With AI being available, I see one thing happening. For example, Claude Code allows people to connect Jira or ClickUp, and then they connect GitHub to get the work done. If you can bring in a feature of the AI that can help do the project management and the code commits in a single MCP since the project management is in GitLab [Private Offer Only] and the code is in GitLab [Private Offer Only], that would help get rid of Jira and all these things. This will have two benefits. One, the onboarding will be easy. The second thing is people will not have to pay an additional amount for Jira or ClickUp.
I was using GitLab for my personal project for the last five years, not for professional projects.
I never had any issue with GitLab. For me, it is stable.
For me, GitLab was a scalable solution.
I never had any problem and never had to reach out to the support of GitLab.
I have used the cloud version of GitLab. I have not tried the self-hosted version, so I cannot comment on that.
I never got a requirement to have a self-deployed GitLab instance.
Developer time is important. If you save time in the development with GitLab, that is a value of money. If things are getting done faster, then that is a good ROI.
It varies team by team, but based on my experience, GitLab saved my time between 10% to 15%.
I was using the free version of GitLab , but I think the price is comparative and not a major differentiator.
When I started using GitLab, I wanted a combo of the features. There was ticket management, there was the wiki, and there was a CI/CD pipeline, everything was there. GitLab was the first to provide all these things, and later on, GitHub has taken all these things, but GitHub is a follower. GitLab is the pioneer of these things. That is why I started taking it and that was the main motivating factor for me.
GitLab is on its own cloud.
I have purchased security products from AWS Marketplace, but that is not related to GitLab. It is AWS, and I used Kaspersky for my servers when I was doing PCI DSS for one of my companies.
I rate GitLab an eight out of ten.
My use cases for LaunchDarkly involve managing risk from new features such as AB testing and canary releases for features with gradual rollouts. This type of work is fundamentally about managing risk and testing new features.
I haven't used LaunchDarkly to manage any AI in production; the only thing I've used it for is feature flags for the most part.
What stands out to me about LaunchDarkly is that it's super easy to use. I appreciate that you can serve the feature at a percentage and that you can add users by email. For example, I used it in the past to do internal-only testing of the feature in production, which was very helpful.
From what I've seen, the management of feature flags in LaunchDarkly is pretty good. I don't have any other reference point to compare it to, but it's pretty simple to create a new flag and then edit the flag and increase or decrease traffic to that flag. I'm not an expert on feature testing, but for what I've used, it works for what I needed.
If LaunchDarkly goes down and you don't have it set up right, it could be a problem for you. I think that's a little bit on user error as well.
I would like some sort of a local instance to be available.
I've been working with LaunchDarkly overall for at least a few years, probably around three years.
I've seen lagging, crashing, or downtime with LaunchDarkly. There was an outage, and that's what I was referring to. If there's ever an outage, I think you can define a default experience in your code, but I don't think we did that well. It might have reverted to an experience that we did not want the customers to see. For instance, my company developed a new version of our checkout page, and it was behind a LaunchDarkly flag, but it was serving 100% traffic to that flag. But when LaunchDarkly went down, it started using the prior checkout page, which is not as good of a page, which is why I'm saying that it's a problem if LaunchDarkly goes down.
Regarding scalability, I think LaunchDarkly is pretty scalable. I've never had issues with it scaling.
I've never actually used anything similar to LaunchDarkly, but I'm aware that there are competitors; however, LaunchDarkly is the only one that I've used.
The initial deployment of LaunchDarkly was handled by a platform team that managed that initial setup, but as far as integrating it to my service, it's pretty easy to just create a LaunchDarkly client, much like any other type of client for any external software that you use, and then just go ahead and start using the flags.
LaunchDarkly usually does not require any maintenance on my end. It's usually taken care of. The only time we have maintenance is if we're not using any flag anymore, or we make it a permanent feature instead of a feature flag; then we'd have to go into the code and clean it up to delete the flags and then delete it from LaunchDarkly. But in terms of maintenance outside of that, there isn't much required.
On a scale from 1 to 10, I would give LaunchDarkly an 8. I would definitely recommend it to another customer. It's always worked for me, except there have been outages here and there, but very rarely. I'd say it's pretty good for the most part.
