4 ms·

How would you characterize the quality of CircleCI? I've spent quite a few hours trying to work out mysterious bugs in a build process that runs fine locally. T

• wlll 6y ago
  As an end user I've been pretty happy with it. I've used Jenkins, Travis, Github and Circle mostly, and of those I hope to never have to use Travis or Jenkins again, and I've only really used Github for some simple stuff, but rather enjoyed the experience. Circle however I've used with some fairly lengthy and complex build processes involving multiple parallel builds of Rails apps during upgrades and it's handled the workflow well. I think they've improved the UI a bit recently, but it's still pretty complex though.
  • ciceryadam 6y ago
    Have you tried Teamcity? https://www.jetbrains.com/teamcity/ https://www.jetbrains.com/teamcity/
    • wlll 6y ago
      No, not yet.
• jmchuster 6y ago
  We've seen great results since switching from Circle to Buildkite, not the least of which is cost, but you have to be willing to do a little bit of your own IT work.
  • sylvinus 6y ago
    I second Buildkite, one of the best choices we made at my previous company.
    • sundvor 6y ago
      Buildkite is awesome. Thirded. Love the clear UI, yaml based dynamic pipelines and ease of integration. Coupled with Terraform for us.
    • beilabs 6y ago
      Another happy Buildkite customer here. Beautiful UI and it just works really well.
    • DuskStar 6y ago
      Buildkite + preemptible GCP instances has worked great for where I'm working right now!
  • devocris 6y ago
    But isn't that the point of Circle...not having to do any IT work? At some point the cost of Circle becomes negligible, especially when you consider how much your time is worth...and that you don't have to do any maintenance.
    • jmchuster 6y ago
      Yes, if you are completely allergic to IT work, then your options are more limited. In terms of time, I would say the initial setup cost us a day or two, but after that our EC2 build box has just been fire and forget. edit: I'll also add that in terms of time, I feel like most of the time in build pipelines is actually spent in tweaking, adding, and modifying the build configs, as opposed to the servers themselves (and you might also value developer time differently from devops time). I have found Buildkite easier to work with than CircleCI in this regard, and thus saved much more time overall.
• davnicwil 6y ago
  You might be interested in what I'm building over at https://boxci.dev https://boxci.dev The motivation for this was exactly this problem. With Box CI your local build is your CI build because it runs jobs via agents on your own hardware so you can very easily debug / understand what is going on.
  • frenchman99 6y ago
    Wow, that looks so practical ! And no server cost/setup/maintenance, I guess. The thing I'm concerned about that doesn't seem addressed on your home page is security : by installing your agent on my machine, I'm basically giving you access to my machine non-stop, no ? What guarantees do I have that your agent can't be used as a backdoor ?
    • davnicwil 6y ago
      Great question! Firstly, and very importantly, the agent is open source (https://github.com/boxci/boxci https://github.com/boxci/boxci) so you can see exactly what it does and even build it from source if you want. I should mention Box CI isn't launched yet, everything is still in beta including the agent. The Box CI service doesn't have any way to send requests to or send commands to agents - the requests are one-way, agent to service only, with agents polling the service for build jobs to run, running them, and sending logs and results to the service. Build scripts and configuration are all in your source code. This is a tradeoff, because it definitely means you have to trust your source (and everyone committing to it) if you're going to be running agents on your dev machine for instance. There are obviously mitigations to this though, like running the agents on a dedicated Cloud VM with nothing on the filesystem and internet access locked down to package manager and cloud provider hosts. A future plan is to provide pre-configured VMs for various cloud providers so this can be set up in a few clicks for low cost ($20 a month or whatever a reasonable build machine VM would cost). The real security point of the the agents though, the other side of these tradeoffs, is that your code and your production secrets never leave hardware you control - the CI service never has access to them. That's a massive security advantage Vs centralised CI services which do have full read access to your source and effectively full write access to your production infrastructure via keys you give them - compared to what I've described above this is a massively bigger and more dangerous potential security hole. You can probably tell by the length of this comment I'm super interested in this aspect (along with dev experience I see it as the key advantage of the model and one of the reasons I'm building it) there's a lot more depth to this and if you'd like to discuss further, I'd love to :-) Email's in my profile.
• bdcravens 6y ago
  v1 was good for us, but when they moved to v2, it just seemed like far more work for us than Codeship Pro.