Pavan Belagatti

Posted on Apr 24, 2018

What is your favorite CI/CD tool and why?

#discuss #devops #ci #cd

Top comments (23)

Devin Handspiker-Wade • Apr 25 '18

GitLab-CI:

Supports Docker containers, SSH, or virtual machines
Easy to configure YAML
Can self-host a runner while also providing a free shared runner for smaller projects
Can be used for non-Gitlab projects
Config is tracked in the repo
Files can be cached between runs based on a dynamic key
Jobs can be tested locally before committing the config
Can run jobs based on the branch or tag pushed
Job can be scheduled to run on a regular basis
Provides artifact storage (As far as I know Bitbucket doesn't)

Evan Oman • Apr 25 '18

Very cool, we just got Gitlab Enterprise at work (after sitting on Gitlab 6 for years) and I am excited to try the CI stuff out.

Devin Handspiker-Wade • Apr 25 '18

Do you mean "...sitting on Github"? 'Cause CI access is included even in the free GitLab packages.

Evan Oman • Apr 25 '18

Hmm, yeah our local Gitlab instance only has the Git part available as far as I can tell.

Sten • Apr 24 '18

Bitbucket Pipelines:

It's bundled with Bitbucket, no need to bring another tool
Supports Docker out of the box
Allows me to use the same commands as the one I run in my terminal
Supports different forms of deployment pipelines

But I'm biased since I was the lead product manager for it back when I was at Atlassian 😅 (still think the team did a stellar job - and it's great to watch it grow from the sidelines now).

Kodengo • Apr 25 '18

The pipeline config is close to the code which makes it visible and accessible to the devs. This makes the pipelines more dev-ish than some pipeline scripts that sit in another repo that I cannot even access and are maintained by an ops guy that sits in an office 3 buildings away...

Pavan Belagatti • Apr 24 '18

Even I like Bitbucket but what I don't like is the outdated UI and it is a bit confusing.

Dian Fay • Apr 24 '18

I've had a love/hate thing going with Jenkins for about a decade now. It's fantastically powerful but an absolute bear to use.

Kodengo • Apr 25 '18

Jenkins - The swiss army knife of CI tools.
I like the options they now have to represent pipelines as code. That way you can define maintain and scale the build definitions in code and have them versioned with your project.

Pavan Belagatti • Apr 24 '18 • Edited

Same here, I have a love/hate relationship with Jenkins.

I like Jenkins because,

So many plugins
versatility
Super nice integration with Github or Bitbucket
The pipeline as code is wonderful
The declarative pipeline is good

I hate Jenkins because,

Harder time understanding the point and click nature of Jenkins
Many of them think 'it's not a modern CI' tool.
can't write logic for your pipeline because the tool your using had its own logic
Documentation is not at all good
Its configuration(the server) cannot be defined as code which is a pain to manage plugins, credentials, etc
Declarative is amazing, but the lack of documentation makes you insane because you only find info for scripted pipelines
There's an annoying bug that doesn't let you save the project configuration in a github organization.
UI looks awful *The API is horrendously, staggeringly bad
There's no good way to handle multi-branch projects

I prefer CircleCI, Codeship or Shippable.

Dian Fay • Apr 24 '18

I was actually pretty happy with multibranch pipelines at my last job! The only problem is the same problem with pipelines in general -- poorly documented Groovy APIs and script approvals.

Evan Oman • Apr 25 '18

poorly documented Groovy APIs

So true! I was just trying to do something very simple and I couldn't find any info on how to interact with plugins (eventually figured it out by modifying an example).

Dian Fay • Apr 25 '18

It's really amazing that in 2018 the way you get your coverage report in Pipelines is still

step([
  $class: 'CoberturaPublisher',
  autoUpdateHealth: false,
  autoUpdateStability: false,
  coberturaReportFile: '**/cobertura-coverage.xml',
  failUnhealthy: false,
  failUnstable: false,
  maxNumberOfBuilds: 0,
  onlyStable: false,
  sourceEncoding: 'ASCII',
  zoomCoverageChart: false
])

because there isn't a proper step defined.

Patricio Cano • Apr 26 '18

Shameless plug: I created a new CI/CD tool called AlloyCI.

It is written in Elixir, and is heavily based on GitLab CI. It, in fact, can use the GitLab CI Runner as an executor for all the jobs. It also provides its own runner, that is a fork of GitLab's.

For the time being it is still in beta, but the main goal is to make it a viable option for people looking for a new CI tool.

As of right now, it has about 85% of the functionality that GitLab CI has, configuration is written in JSON (but we are thinking about transitioning to YAML), and it should be pretty straight forward to install and use. We provide Docker Images to get started quickly, and also a "Deploy to Heroku" button to try it out there too.

The main use for AlloyCI is to install it on premises, and add as many runners as you need. Since the runners are written in Go, binaries are available for all platforms. It supports Docker, Docker+Machine, SSH, VirtualBox, and Shell as ways to execute your builds.

With Docker+Machine you can have auto-scalable runners, e.g. one machine is in charge of deploying and destroying other runners. This works great with Digital Ocean. Runners will be created as needed, and everything about how many are created, how long they stay up, and more can be easily configured.

Since it is written in Elixir, it consumes very little system resources, it's highly stable, and should be able to process large amounts of concurrent requests.

I would love it if you could give it a try, and tell us what you like, what you don't like, what you hate, what you love, etc.

We really want to make AlloyCI a true alternative ❤️

Pavan Belagatti • Apr 27 '18 • Edited

Nice. Yes, transitioning to YAML is a good option, it makes the tool easy to use. All the very best:)

Dimitri Merejkowsky • Apr 25 '18

Note:

I spent many years working with Jenkins and switch to GitLab CI 2 years ago. I've also used travis.

I like GitLab CI the most, here's a list of nice features:

Bundled with GitLab (doh)
Excellent documentation
You can always deploy because your CI code lives next to your production code. In Jenkins, if you changed the job config without adding it to version control you're screwed
gitlab-runner runs everywhere (macOS, Linux, Windows) and is very easy to configure/install (just a go executable and you're ready to go)
Clean yaml based config
- Jobs declaration with stages and environment name is awesome

Supports Docker out of the box

Integrated with Kubernetes

Nice REST API

And here are a few things where Jenkins is better:

Trying to figure out why your job is pending is not obvious and you have to be an admin to see all the running jobs.
Every job starts with a completely clean git repo. You must use things like cache and artifacts to transfer files across jobs and pipelines. Sometimes I would just like a 'don't clean the git repo after checkout' option.
If your gitlab-ci.yml go out of sync accross branches, things can get tricky...
GitLab CI really insist on having one git repo per project: jobs across projects are hard to maintain.
In the same vein, you cannot have 2 different jobs depending on which folder of the source code has changed.
No plugins. You cannot for instance get a list of tests that passed with their history, for instance.

Devin Handspiker-Wade • Apr 25 '18

You can have the "'don't clean the git repo after checkout' option". It's under "Git strategy" in runner settings. Doesn't really make a difference if you are using containers as they're disposed after a job completes but if you are using are SSH executor it doesn't clean the workspace.

Dimitri Merejkowsky • Apr 25 '18

Wow I somehow missed that. Thanks !

Kevin LaBranche • Apr 25 '18

Cake scripts that are then called verbatim via whatever tool I want. Script is sourced with project and calls to it are the same locally as with whatever CI/CD tool you choose. Keeps the "tool" exactly the same as the local setup and allows for easy migration to another tool (not that one would do that much).