CircleCI is a software delivery engine from the company of the same name in San Francisco, that helps teams ship software faster, offering their platform for Continuous Integration and Continuous Delivery (CI/CD). Ultimately, the solution helps to map every source of change for software teams, so they can accelerate innovation and growth.
$0
for up to 6,000 build minutes and up to 5 active users per month
Docker
Score 8.9 out of 10
N/A
Docker Enterprise was sold to Mirantis in 2019; that product is now sold as Mirantis Kubernetes Engine. But Docker now offers a 2-product suite that includes Docker Desktop, which they present as a fast way to containerize applications on a desktop; and, Docker Hub, a service for finding and sharing container images with a team and the Docker community, a repository of container images with an array of…
CircleCI is perfect for a CI/CD pipeline for an app using a standard build process. It'll take more work for a complex build process, but should still be up to the task unless you need a lot of integrations with other tools. If you have a big team and can spare someone to focus full time on just the CI/CD tools, maybe something like Jenkins is better, but if you're just looking to get your app built, tested, and delivered without a huge amount of effort, CircleCI is probably your preferred tool.
You are going to be able to find the most resources and examples using Docker whenever you are working with a container orchestration software like Kubernetes. There will always some entropy when you run in a container, a containerized application will never be as purely performant as an app running directly on the OS. However, in most scenarios this loss will be negligible to the time saved in deployment, monitoring, etc.
The "phases" their config file uses to separate out options seem very arbitrary and are not very helpful for organizing your config file
No way that I know of to configure which version of MongoDB you use. You have to write your own shell script to download and start MongoDB if you want a specific version.
I have been using Docker for more than 3 years and it really simplifies the modern application development and deployment. I like the ability of Docker to improve efficiency, portability and scalability for developers and operations teams. Another reason for giving this rating is because Docker integrates CI/CD pipelines very well
It's pretty snappy, even with using workflows with multiple steps and different docker images. I've seen builds take a long time if it's really involved, but from what I can tell, it's still at least on par if not faster than other build tools.
Unless you have a reasonably large account, you're going to be mainly stuck reading their documentation. Which has improved somewhat over the years but is still extremely limited compared to a platform like Digital Ocean who invested in the documentation and a community to ensure it's kept up to date. If you can't find your answer there, you can be stuck.
Circle was the first CI with simple setup, great documentation, and tight integration with GitHub. Using Jenkins was too much maintenance and overhead, TeamCity was limited in how we could customize it and run concurrent builds, TravisCI was not available for private repos when we switched.
The reason why we are still using Docker right now is due to that is the best among its peers and suits our needs the best. However, the trend we foresee for the future might indicate Amazon lambda could potentially fit our needs to code enviornmentless in the near future.
It is the only tool in our toolset that has not [had] any issues so far. That is really a mark of reliability, and it's a testimony to how well the product is made, and a tool that does its job well is a tool well worth having. It is the base tool that I would say any organisation must have if they do scalable deployment.
It has eased the burden of standardizing our testing and deployment, making onboarding new developers much faster, and having to fix deployment mistakes much less often.
It allows us to focus our process around the GitHub workflow, ignoring the details of whatever environment the thing we're working on is actually hosted in. This saves us time.
