Shippable offers developers the ability to automate their workflow, from code review to production rollout, all without writing a single line of code. The build and deploy scripts have to be written in a separate config file which is stored alongwih the code files. This is good for portability Shippable takes over the moment a developer pushes some code into a repository, managing all the steps needed to push the code into production. It is all automatic and no interaction is needed to build new versions, it is all trigerred by the git push into the code repository At its core, the platform offers developers a unified, Docker (container-based) application delivery pipeline for heterogeneous source control systems, making it well-suited to unit testing, functional testing for those deploying microservices, stress testing, or security testing. The platform also supports both script and UI-based pipelines. Scripts are more configurable, whereas the visual pipelines are better for simpler cases and provides more insight into he process for everyone. I prefer the second approach for most of our projects. Also, a feature called Lighthouse allows users to “subscribe” to a Docker image and be notified of any changes, regardless of who manages it. If a change is detected, This is again good because the developers can know that the development environment and not the codebase itself has changed. Builds triggered due to this then should be analysed separately as it is more likely a problem with the changes made in the docker image.

1. Build on your own host - Developers can set up Docker containers on their own servers and run Shippable in there. So, you dont need to store your data in external servers, giving better security and savings. 2. Configuration file to describe builds - Builds are described in the shippable.yml file located in the root of your project. So, its more flexible and also can be stored in you code repository as it is just a plain-text file. That is, even the config code can be versioned and reviewed later. If you are coming from Travis CI, Shippable reads your .travis.yml file directly so you can try it out directly - this is a pretty nifty feature. 3. Docker integration - Shippable is built using Docker, a popular Linux container. It was originally built using it's own container but when that started to become too complex, they switched to using Docker. Since the beginning Shippable was different from other CI tools because while Shippable uses a container (Docker), traditionally CI tools have used virtual machines to manage their workloads. Running on docker means creating and destoring build environments are always a pleasure and there is no chance for any leftover from previous version. 4. It also supports testing against multiple runtimes, versions and environments for eg. different versions of the language, library and OS. So, it lets you test the code more thoroughly in many scenarios.

I like Shippable because it is a all-in-one solution for our build,packaging and deployment needs. It is easy to configure the .yml file to test the project from source code, build and package it into a binary if the tests pass and then automatically deploy it to test or master environments. It lets you automatically tag the package with version information and store all the versions for future access and rollback. It is easy to think of it just as a deployment solution, but it also has support for test reports and a dashboard to monitor the status of previous tests and change of coverage percentage. This helps in keeping a quick tab on many projects without having to go into all the projects and analyze manually. I also like that they have administrative permission manager to control unauthorised access from third parties that you integrate with the project. The test results can be made public without storing the keyfiles publicly.