The difference between Snap CI and CircleCI

Continuous Delivery with Snap CI

TRY US FOR FREE

Snap is a hosted CI/CD product that was built guided by the best practices in the Continuous Delivery book.

While Snap supports all the features required for Continuous integration and deployments--out-of-box support for many languages, databases and deployment options; enhanced support for Pull Request workflow; automated branch tracking--that is where the commonality with other hosted tools like Travis, Circle, etc., ends.

Snap makes application delivery simple

Hosted CI tools like Travis and Circle CI constrain your application delivery to a monolithic test-and-deploy workflow. While this is very easy to get started, it soon proves insufficient because that model doesn't afford much flexibility.

Snap encourages best practices like trunk-based development

Most teams don't want to automatically push every commit to production. At a minimum, you want to deploy to a staging environment, run a smoke test, and then deploy to Production.

But the 'test-and-deploy' model doesn't afford much flexibility to do this and teams have to end up using branches for their deployment process. For example, they end up maintaining a “dev” branch and merge to the "production" branch to deploy to production. This introduces a lot of friction by having to do "big bang" merges, resolve conflicts and so on, and creates anti-patterns like those in Gitflow. In addition, it doesn't embrace CI best practices like trunk-based development.

If you want to learn more about these kinds of issues, you can visit our blog to read more.

Snap promotes your build artifacts between environments

Let's say that you want to promote builds between environments like "QA" or "Staging", do manual exploratory testing, and then deploy the same to "Production". The simplistic 'test-and-deploy' concept is limiting because you have to maintain branches for each target environment you want to promote builds for.

More importantly, because the promotion process is essentially a merge which can include merge conflict resolutions and so on, what was tested in a QA or Staging environment is not necessarily what gets deployed to Production. This reduces confidence in the process because you're not testing and deploying the same artifact in different environments.

Snap increase your visibility

Another huge limitation is that the test-and-deploy model limits visibility into the development process. If you are using branches, as mentioned before, it is immensely hard to track the flow of changes from the source repo to Production.