An incredibly useful tool for automating any kind of testing and deployment scenario
March 30, 2017
An incredibly useful tool for automating any kind of testing and deployment scenario
Score 10 out of 10
Vetted Review
Verified User
Overall Satisfaction with CircleCI
CircleCI is being used by our organization for continual integration and automated deployment of Drupal and WordPress websites to Pantheon, among many other smaller CI jobs. It is used entirely by our Development and DevOps team members. It allows us to commit a simple config file to Git that controls the way that our software gets deployed, making the tedious job of deploying changes for hundreds of websites regularly much simpler.
- Full customization and scripting abilities. Using tools like bash scripts, SSH, and Node, running almost anything upon committing some code to GitHub becomes possible.
- Integration with all of our favorite services. GitHub and Slack in particular are crucial to our business and CircleCI's integration is seamless and full-featured.
- Great config file syntax. Many CI services require you to perform advanced configuration in a UI. This is fine at first (and CircleCI offers this for many options available), but when you start needing to manage a large number of projects, committing configuration changes to a Git repository is more consistent and maintainable than making the change many different times manually in a UI.
- It would be nice if you could configure everything via the YML file. Some things are only available via YML, and some things are actually only available in the UI, and many other things have full overlap between the two. I'm sure there are good reasons for this, but this is a pretty confusing situation. For example, certain PHP versions are only available on certain Ubuntu releases. Configuring the PHP version is done via the .yml file, but configuring the Ubuntu release being used for the build has to be done in the UI. This can easily lead to things not building properly.
- 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.
Travis has full YML configuration in areas where CircleCI is slightly lacking still, which is great, but CircleCI offers more features, settings, and potential performance.
Codeship is simpler to use, you can use it entirely from their UI without modifying your Git repository at all. To some, this is important, existing Git repos need to be supported without adding files to them.
For others, and this is our situation, the opposite holds true--we'd rather keep our testing and deployment configuration along with our code in Git than managed somewhere separate. I believe this is a better approach in the long-term, especially when managing a large number of projects.
It also means most of our team members don't need to be in the CircleCI interface at all, possibly ever. They get added to the team, someone turns deployments on in CircleCI for the project, and then everyone can collaborate on making changes to the configuration, relying on Git's excellent merging abilities, rather than having multiple people potentially in the UI modifying configuration simultaneously, potentially reverting each others' changes.
Codeship is simpler to use, you can use it entirely from their UI without modifying your Git repository at all. To some, this is important, existing Git repos need to be supported without adding files to them.
For others, and this is our situation, the opposite holds true--we'd rather keep our testing and deployment configuration along with our code in Git than managed somewhere separate. I believe this is a better approach in the long-term, especially when managing a large number of projects.
It also means most of our team members don't need to be in the CircleCI interface at all, possibly ever. They get added to the team, someone turns deployments on in CircleCI for the project, and then everyone can collaborate on making changes to the configuration, relying on Git's excellent merging abilities, rather than having multiple people potentially in the UI modifying configuration simultaneously, potentially reverting each others' changes.