GitLab

I like that GitLab CI is easy to version and review because the pipeline is defined in a yaml file stored in the repo, so changes to the build and test workflow go through the same merge request process as production code. It's been great for standardizing how we run Playwright and Selenium suites, API tests, and contract checks for consistent container images, environment setup and predictable logs when something flakes. Test artifacts are also a big win for debugging in being able to publish test reports, screenshots, traces, and videos per job makes triage faster than digging through raw console output.

The built in features, especially automation in DevOps, SAST/DAST security protocols, and ease of scalability within our infrastructure.

1. Integrated CI/CD: The fact that the CI/CD pipelines are all seamlessly integrated into the GitLab offering is the killer app in and of itself. Being able to set up all of this through the '.gitlab-ci.yml' configuration file right in the GitLab repository configuration is infinitely better than the way we had to manage Jenkins servers in the past. 2. Code Review & Merge Requests: Code review screens are nicely designed. Features such as in-line commenting and viewing the status of the pipelines in the Merge Request are all excellent ways to facilitate team collaboration. 3. Integrated Container Registry: Docker is a big part of what we do, and being able to store our containers in a registry right in our GitLab installation eliminates the need to manage third-party storage services.

A single runner operation can become its own mini-platform where jobs get stuck, runner capacity planning is a pain, and keeping containers and dependencies stable across upgrades takes a lot of effort (especially once multiple teams pile onto the same fleet). Merge request pipelines are useful, but it's important to understand that they run against the source branch content (not the merged result by default), so there are times I still want merged-result testing to catch integration conflicts early. Also, caching and artifacts are easily misused at first, where cache is best for reusing dependencies, while artifacts are better for passing build outputs between stages and downloading reports later.

It is very complex to set up the service to begin with. The product is very complex and requires established system experience to be competent in. Costs can increase rapidly when expanding across infrastructure.

1. Resource Intensiveness: Since we use a self-managed instance, the process can be very resource-intensive, especially if theres a large set of pipelines running at the same time. 2. Steep Learning Curve: Because this platform does so much, sometimes the UI can be overwhelming for junior developers brought on to the team, as theres too much going on, represented by options on menus, & so on. 3. Debugging CI Pipeline: At times, debugging a syntax error involving CI pipelines can be frustrating; a more interactive experience would be nice for speeding up the process for CI pipelines linting tools.