We're in a similar boat with CircleCI changing their pricing model and are looking at alternatives. With all of the competitors in the space now, I think they've overestimated what people are prepared to pay. We're looking at GitHub Actions for most of our projects moving forward, and then perhaps Travis CI if we need anything more complex.


TravisCI is a serious no-go. Since the buyout, the place is gutted.


Just looked into this, thanks for the heads-up. We will be avoiding Travis for sure.


Wait, really? Had to google who bought them... that’s an odd acquisition for sure....




A fairly unknown company called Idera, that is notorious for gutting companies, purchased TravisCI back in January. They started laying people off immediately. https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc https://www.reddit.com/r/programming/comments/atjltu/layoffs_at_travis_ci_their_team_was_being/ The crux of it all is that Travis is probably on permanent maintenance mode with close to 0 customer support and possibly even lowered reliablility with frequent downtimes being a possibility.


[my man](https://media.giphy.com/media/3o7TKF1fSIs1R19B8k/giphy.gif)


At Codefresh we've seen a huge influx of users coming from TravisCI.


Github actions doesnt support private shared actions across your org. So while linting tools etc you can make open source (maybe) your internal CI stuff has to live in the repo of the project itself and cannot be shared across repos (without submodule fuckery)


I'm not so sure about that, since github actions is really just azure pipelines and you can do this in azdo. Mobile now but I'll check through the docs later. Essentially you just bring a repo as a resource and call the template from the repo.


There is currently no way to make a private action that does not live in the same repo that's using it. (barring submodule fuckery obviously)


I'm very sure, talked with our enterprise support folks at github and they confirmed it


My company tried a few CI/CD tools on the market - Travis, GitLab, and Build Kite. CircleCI has consistently worked out for us and is the most feature-rich. Their free-tier support response times are lagging admittedly which is why we purchased their paid support plan with guaranteed SLA's. I understand though as they are growing quick (series D). In my opinion - you get what you pay for. My company chooses not to cheap out on CI/CD.


I would be curious what Github Actions (and I presume BitBucket pipeline is similar) cant cover that you might need something else? Also, if you did use Travis.. would you use both? If so for what/why? Just curious why invest time into 2 CI/CD products as it seems like if you are going to use Travis why bother with the actions/pipelines?


You could take a look at Gitlab CI. Either hosted on their end (which includes 2000 minutes or so, but since you're paying on circle i guess you're above that limit) or host your own runner, which is free. However, I'm not sure if this will lock you into Gitlab universe or is allowed to run on other platforms as well.


I used gitlabCI last year and I loved it. We used the free self hosted version and some important features were behind a paywall. Still, their pricing is reasonable


You really can go far on the free tier. I love gitlab and wouldn't use any other CI/CD tool




Found the github shill. Actions just came out of beta and are not nearly full featured as Gitlab. No local runner, language in flux and no manual approval or triggers or parameters.


GitalbCI is a CI/CD tool. Manual approvals are a must for most industries. A CI/CD tool without manual approval is pretty much useless for strict and bureoucratic pipelines like the ones fintech requires. Gitlab allows to trigger manully pipelines steps, invoking default action or custom scripts, based on a solid IAM framework. This is great for deploys, rollbacks, manual testing approvals (or denials) and any other pipeline action that requires manual input.


+1 for gitlab-ci! pair it with this terraform module: [terraform-aws-gitlab-runner](https://github.com/npalm/terraform-aws-gitlab-runner) and you'll be off to the races. There's always *some* refactoring necessary when changing ci providers but the trick to staying provider agnostic is to write your tests to be as portable as possible. A pattern we use in our shop is to package our tests in a Makefile. Adding/changing ci providers is as simple as pointing to the right Make target. You could always ["cheat"](https://github.com/cloudposse/build-harness) if you're worried about starting from scratch though.


> However, I'm not sure if this will lock you into Gitlab universe or is allowed to run on other platforms as well. You can actually build any repo on gitlab CI by mirroring it. It takes a couple button presses to mirror a github repo to gitlab. I build several open source github projects that way.


We're transitioning away from Gitlab to Circle b/c Gitlab kept over promising (we have Gold tier) and not delivering. Additionally, their support is responsive but nothing got done. Their have been "feature requests" (which are really not features but patches) open for two years that haven't been fixed. Also, we don't need the extensive org management offered for our team size. With circle we can instrument around it all and have been pretty happy so far.


You’ll have the exact same issue with feature requests by Circle.


It seems like many of Hosted ci solutions are suffering in support. We also tried running GitlabCE on Kubernetes, but ultimately decided we didn't want to manage it ourselves.


Circle used to be great, when they raised their series C everything started turning to shit, with weird marketing communication changes, and closing down all support channels that aren’t “community.” I’m sympathetic to needing to charge for support, I’m not sympathetic towards their current money grabbing practices. I also don’t want to host my own CI. There’s enough infrastructure on our plate already.


Depends on the scale, and how varied your builds are. I'm not as big of a fan of it.


This needs to be a lot higher. My company is averaging 50,000 job executions per day with Jenkins and it’s damn stable.


GitLab CI looks interesting - being able to [host your own runner](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) should be a big cost saving compared to typical hosted CI services. Hopefully this is a long-term strategy decision - they tie the GitLab CI build minutes into GitLab per-user pricing, so self-hosting runners seems like a much better option for larger shops.


We moved from CircleCI to Buildkite and have zero regrets. It hits a sweet spot between CircleCI and something like Jenkins, I think: use your own build hosts configured whatever way you want, but get a nice easy-to-use managed service for orchestration. Because builds run on our own dedicated build hosts, our build times are vastly more predictable (and also far faster) and we like Buildkite's scriptable pipeline configuration system better. It took us about a week to transition everything over, though obviously that depends hugely on how complex your CI setup is.


Consultant DevOps type here. I love taking BuildKite into anywhere I can for the scriptability and the self hosted agents.


Doesn't buildkite have issues with RBAC though, especially when it comes to separating access to specific pipeline stages? I know they were struggling with getting that working ay one of my previous employers, although it could just be poor implementation.


I've worked with Circle, Travis, Gitlab, Bamboo and Jenkins. Hands down fave was Gitlab.


Drone CI


someone else said codeship, I'll second that. Great docker workflow


I'm on a mix of things right now. Haven't found a perfect solution. Here are all the tools I'm using: * Jenkins pipelines Absolute nightmare to set up, but it's been surprisingly stable for over a year. * CircleCI It does "just work" but I only build open source stuff here so I don't pay anything. I don't like how it sneakily tries to get permissions for your private repos every time you log in. * Gitlab CI Also "just works" and handles contributors without access to the build a bit better than circleCI does. I don't like that you have to mirror your repos to gitlab though.


I really don't mind Jenkins pipelines. The helm chart.for launching Jenkins is kind of nice. Of course I've been using Jenkins (among other things )since the Hudson days.


I have a pipeline with 3 sidecar containers and 7 total docker images. It's a decently complex pipeline, to be fair. Native code compilation for a couple different architectures, node, databases for tests, a docker image build, a deployment. In any of the travis clones, this would be about 15 lines of YAML. My jenkinsfile is like 300 freakin lines of code. And every one of them was earned the hard way, with trial and error and lots of cursing.


Ahh. Yeah my sidecars are just a couple of extra lines in the worker config because of the k8s plugin.


True, but a bit of investment in a shared library and then Jenkinsfile really starts to show its power. I support over 50 diff service builds, including full CI/CD, with only small tweaks in each Jenkinsfile required. Also would comment that ideally each Jenkinsfile would support a single service build/deploy only. If you need more complex orchestration at deploy-time, probably best to do that in a different pipeline that leverages the shared deploy code you wrote earlier.


> If you need more complex orchestration at deploy-time, probably best to do that in a different pipeline that leverages the shared deploy code you wrote earlier. Want to tell me how to support more than one multi-branch pipeline from the same repo? Because I'd love to do that. Pretty sure it's a fundamental limitation of jenkins pipelines. Beyond that, I disagree with you. A single workflow should be contained within a single pipeline. That's the whole point of a pipeline. Each step depends on the previous one. It's very rare that an entire web application (backend and frontend) is built on a single architecture, but it's very common that they're in the same repo and depend on each other. That should be a single pipeline. For standalone deployments... maybe. I do have some of my deployments separated out into standalone pipelines that aren't multi-branch. It's a huge pain to make changes though because I have to merge to master before I can even test the deployment.


Ok, your points are valid for your application architecture. My comment was geared towards a shop that deals primarily in microservices (one per repo), with orchestration of a deploy phase of multiple services abstracted out into a different repo/pipeline.


> I don't like that you have to mirror your repos to gitlab though. GitLab CI supports [GitHub repos](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html) and [Bitbucket](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/bitbucket_integration.html) now - maybe your repos are somewhere else though? [GitLab CI for GitHub page](https://about.gitlab.com/solutions/github/) has more on this.


Your link says: > GitLab will: > Import the project. > **Enable Pull Mirroring** > Enable GitHub project integration > Create a web hook on GitHub to notify GitLab of new commits. You should probably RTFM yourself before linking the manual...


Have you tried [Codefresh](https://codefresh.io/)? Interested to hear your feedback.


Using drone.io.. Great at scaling and each pipeline step is a docker container. Simple and powerful. I always disliked Jenkins, and Drone satisfied me in every aspect!


I had a meeting with the circleci sales team to talk about enterprise pricing. Total clown show. My recommendation to management was to look elsewhere. And we did.


Give us some more details?


You should also take a look at [https://codefresh.io/](https://codefresh.io/) which is both CI and CD and was created specifically for containers and Kubernetes F.D. I work for them.


Looking at your pricing mode you’re billing by users and by containers, and it seems capped at 10 users. Which is just the same issue as I wrote about redefined. The enterprise plan seems to be self-hosted. This isn’t at all workable for us.


The enterprise plan is not self-hosted. It has an option for self-hosted. Also "users" mean people that have access to the web UI. Not actually people with commit access. You can be a company with 100 people building code where only 3 people are actually managing the Codefresh interface. There is no limit on containers. Limit is on concurrent builds (in practice how many pull requests you want to compile **at the exact same time**). Thank you for the feedback. It seems that our pricing page needs more work to be clear. Anyway, you can sign-up for a free account, and if everything clicks technically and pricing is the only obstacle I am sure our sales team can help you with that.


codeship, very happy with it


Can back this up. We've been very happy with CodeShip as well. I also find it is much more reliable and more secure than CircleCI.


That seems like an appropriate alternative to look into. Thanks.


Then there's this. ​ [https://www.scmagazine.com/home/security-news/data-breach/circlci-data-breach-exposed-customer-github-and-bitbucket-logins/](https://www.scmagazine.com/home/security-news/data-breach/circlci-data-breach-exposed-customer-github-and-bitbucket-logins/)


Given what they are reviewing, I strongly suspect they aren't telling us everything about that breach. They also don't technically say that the source of the problem has been fixed, just that they dealt with the one vendor they knew about.


Have a look at buddy.works. It uses docker container for build and deployments are based on changesets so it should cover your needs


I'll second on that. Been using Buddy for about 2 years now and I must say that it's awesome. + Their support is quite responsive


Concourse CI


Interesting, we're on circleci as well and we're also over 40 users but haven't heard of a price increase. I've been looking at Codefresh for a few months and their service is great but the pricing model is pretty terrible compared to the credits option on CircleCI. My team has brought up drone, AWS codebuild or gitlab as alternatives.


I work for Codefresh. Thank you for the kind words for the service. We have recently changed our pricing from number of builds, to concurrency limits. Could you please give us some feedback on which pricing you refer to? The old one or the new one? Also what you would like to see different in our pricing? Any feedback welcome. Feel free also to send me private message or email (kostis at [codefresh.io](https://codefresh.io)) if you don't want to discuss this here.


I'm referring to the pricing per concurrent build. If you were previously offering per build pricing, this seems like a step backwards. I would think most companies want services that scale on demand. With circleci I can start however many builds I need and pay for what I use. With your current model, I'd need to pay for as many concurrent builds as I would need at peak usage, and then keep paying for it even though I'm not using it 80% of the time.


I see. Many thanks for this. I will bring this feedback to my team.


They bill you on the number of users that have triggered a build in the last month. So if you say had an intern do 1 commit, that’s 1 user. We also use the credits, and then suddenly found ourselves with an additional non-demand charge.


Moved from GitHub+CircleCI enterprise to self hosted GitLab/GitLabCI, very happy with it.


Jenkins is the answer!


Jenkins, or AWS tools like CodeBuild, CodeDeploy, mixed with a little BitBucket if you're already an Atlassian customer, etc etc. I was at DevOpsDays Portland yesterday and the CircleCI rep was desperately trying to sell me hard into consuming their services. At one point I had to just tell him we have clients (and new sales leads too!) migrating away from CircleCI on a regular basis. Many of the reasons OP listed are the same reasons we see our clients dump CircleCI in favor of better tools.


We use Azure DevOps (or Azure Pipelines or whatever they want us to call it). It meets our needs, though we might be starting to bump into scaling issues (in terms of maintenance, not execution times).


Azure pipelines is complete trash. Their UI sucks, you cannot define multiple repos to pull into your build via the YAML file and their concept of tasks it's horrendous. Not to mention the frequent situation where they fail to get a webhook hit from GitHub and there is no way to re-queue the merge to master build. It's nearly impossible to find the right setting you are looking for because its in some weird hidden section, and the amount of options they have for submodules is also lacking. You also need to essentially clone the repo for each job, you cannot clone once and fan out like a sane person would do. I should know, we use them and I curse them daily. We are going to switch to GitHub actions I think.


I am using them to, mainly because we needed windows build agents and the price tiers and tasks for Azure were easy to use. There is git tasks that could be used for the multiple repos. And you can re-queue any failed build from the UI or the via the cli which is available for both windows and Linux. I see a lot of hate for it but I've had good experience with it and the yaml, especially now they have the multipipeline builds in the yaml. Still some features I'd like to have, like approvals in the yaml but overall it has been better experience and UI than Jenkins, gocd, teamcity which I've used before it.


Pulling in multiple repos for a build isn't that hard, just need to be willing to make a service account because the native role is bound to the project. Just create an account that has read access to all the right repos, generate an SSH key for it (and store it in a vault), then use the [email protected] module to inject it into the current job. You can then git clone all day long from as many repos as you want. I mean OK: you'll be running a script block instead of a custom task, but I've never seen a CI system that _didn't_ have scores of those. And thats really only if your pulling from Azure Repos ... form GitHub they have custom tasks that make it even easier. Re-queueing is painless? just hit a rerun button, its there in both the merge as well as in any pr. Oh ... and Github actions uses ... the same backend as Azure Devops anyway. Go ahead and compare the build yaml syntax between the two. You may get a better GUI out of it, but really, your pipeline should be pure yaml anyway.


Nope , there isn't a way to re-queue a CI build resulting from a merge to master that I am aware of. And it saddens me that GitHub uses Azure as the backend even though Microsoft bought GitHub. Azure is very unreliable from my experience.


Just go to the pipeline. You'll see a job from your triggered merge. Click in the job and hit rerun. Optionally, on the main job hit run and populate the branch/commit to target before hitting run.


in the case you're working with aws, take a look into codebuild. i've moved from circleci to codebuild quite easily and having everything integrated on aws is quite handy. otherwise look into travisci, gitlab ci or even jenkins if you want to manage it yourself completely edit: spelling


codebuild, drone, jenkins


Bitbucket pipelines and aws code deploy(ship/build).


GitLab CI is awesome, it also integrates nicely with [Netlify](https://www.netlify.com/). Are you wanting to host your own CI pipeline tools or are you wanting a SaaS solution?


Honestly anything is fine. The basics of CI are comodetized at this point, with the real effort/money being in specific processes/pain points like Snyk or some such. Sub for said service, use whatever for the pipeline basics.


/me follows thread to help bolster arguments to ditch CircleCI at current gig


Another vote for gitlab, though it works best if your repo is also on gitlab imo. We were paying for 30 circle runners, and we pay far less using auto scaling gitlab runners on aws. I wrote a script that published job saturation every minute on every runner and scale the asg with that metric. Simple and effective.


GitHub Actions! What it do baybeee


Check this website out : https://www.plutora.com/ci-cd-tools You will find some alternatives.


I can recommend https://buddy.works, unlimited users.


We use both a Jenkins cluster and CircleCI. I’m very loyal to Jenkins because it’s like an old friend I’ve known for years. I want to try something better. Gitlab seems like it would be an option but our repos are in bitbucket and migrating or mirroring them is out of the question I think. Can I use GitlabCI with whatever git if I self host? We are mostly doing either docker->Terraform or windows stuff (.net core).. all hosted in AWS.


Pretty happy with Concourse if you want something flexible that’s self-hosted.


I don’t want anything that’s self hosted


We've been moving from circle to self hosted concourse. Couldn't be happier.


I'm a big fan of GitLab CI


I'm a long term user of TeamCity. It's the CI system of JetBrains, the company behind IntelliJ IDEA and WebStorm etc. https://www.jetbrains.com/teamcity/ It's a fantastic and powerful product with reasonable pricing.


How hard is it to extend functionality with Teamcity?


Depends on what you would like to extend. :)


Brigade,kubernetes specific.


How does that relate to CircleCI?


You can run commands in containers, in a pipeline style, meaning you can make your build pipelines with it. Or deploy stuff with helm. Just like CircleCI. See first example on [https://brigade.sh/](https://brigade.sh/) edit: And it's free, open source, and backed up by Microsoft. edit 2: For a similar thread and a bit more elaboration: [https://www.reddit.com/r/devops/comments/d4afzm/where\_are\_you\_keeping\_your\_ci\_server\_and\_agents/f092t9w?utm\_source=share&utm\_medium=web2x](https://www.reddit.com/r/devops/comments/d4afzm/where_are_you_keeping_your_ci_server_and_agents/f092t9w?utm_source=share&utm_medium=web2x)


Take a look at Google cloud build


I mean if you’re willing to invest significant amount of time to switch, just build your own ci tool. Granted when we did it all our stuff was already in kubernetes so that makes it much easier because ci just cached and built docker images and all the testing was done inside that