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).
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...
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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.
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).
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
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 ❤️
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)
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.
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.
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).
GitLab-CI:
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.
Do you mean "...sitting on Github"? 'Cause CI access is included even in the free GitLab packages.
Hmm, yeah our local Gitlab instance only has the Git part available as far as I can tell.
Bitbucket 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).
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...
Even I like Bitbucket but what I don't like is the outdated UI and it is a bit confusing.
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.
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.
Same here, I have a love/hate relationship with Jenkins.
I like Jenkins because,
I hate Jenkins because,
I prefer CircleCI, Codeship or Shippable.
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.
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).
It's really amazing that in 2018 the way you get your coverage report in Pipelines is still
because there isn't a proper step defined.
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 ❤️
Nice. Yes, transitioning to YAML is a good option, it makes the tool easy to use. All the very best:)
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:
And here are a few things where Jenkins is better:
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.
Wow I somehow missed that. Thanks !
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).
concourse-ci.org/
Good option.
Codeship because it's integrated with Heroku and easy to use :-)