DEV Community

What is your favorite CI/CD tool and why?

Pavan Belagatti on April 24, 2018

Collapse
 
dhandspikerwade profile image
Devin Handspiker-Wade

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)
Collapse
 
evanoman profile image
Evan Oman

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.

Collapse
 
dhandspikerwade profile image
Devin Handspiker-Wade

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

Thread Thread
 
evanoman profile image
Evan Oman

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

Collapse
 
stenpittet profile image
Sten

Bitbucket Pipelines:

  1. It's bundled with Bitbucket, no need to bring another tool
  2. Supports Docker out of the box
  3. Allows me to use the same commands as the one I run in my terminal
  4. 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).

Collapse
 
kodengo_com profile image
Kodengo

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...

Collapse
 
pavanbelagatti profile image
Pavan Belagatti

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

Collapse
 
dmfay profile image
Dian Fay

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.

Collapse
 
kodengo_com profile image
Kodengo

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.

Collapse
 
pavanbelagatti profile image
Pavan Belagatti • 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.

Collapse
 
dmfay profile image
Dian Fay

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.

Thread Thread
 
evanoman profile image
Evan Oman

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).

Thread Thread
 
dmfay profile image
Dian Fay

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.

Collapse
 
suprnova32 profile image
Patricio Cano

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 ❤️

Collapse
 
pavanbelagatti profile image
Pavan Belagatti • Edited

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

Collapse
 
dmerejkowsky profile image
Dimitri Merejkowsky

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.
Collapse
 
dhandspikerwade profile image
Devin Handspiker-Wade

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.

Collapse
 
dmerejkowsky profile image
Dimitri Merejkowsky

Wow I somehow missed that. Thanks !

Collapse
 
klabranche profile image
Kevin LaBranche

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).

Collapse
 
cassiodias profile image
Cássio Dias
Collapse
 
pavanbelagatti profile image
Pavan Belagatti

Good option.

Collapse
 
rhymes profile image
rhymes

Codeship because it's integrated with Heroku and easy to use :-)