Shippable Brings Declarative Model to DevOps

Slide Show

How Developers Balance Speed and Quality

The biggest challenge with implementing DevOps is the assumption that somebody is available with programming skills to automate the management of IT infrastructure. If an IT organization has anybody who can program, they are usually devoted to writing application code rather than managing IT infrastructure. Developers, of course, could theoretically manage IT infrastructure on their own. But that only takes them away from tasks like developing applications that add value to the business.

To break that conundrum, Shippable has released a new version of its continuous integration (CI) platform that makes it simpler for the average IT administrator to automate the management of the application release cycle using a declarative language. Most importantly, Shippable CEO Avi Cavale says, the Shippable software-as-a-service (SaaS) accomplishes that goal as a cloud service without imposing a specific workflow on that organization. Instead, Shippable is designed to let the IT organization design and implement its own custom workflows.

“What separates Shippable from other CI platforms is that we’re based on a declarative model,” says Cavale.

Based on the YML file type, the Shippable platform also now gives those IT administrators a unified view across all the application release pipelines, says Cavale. To that end, Cavale says Shippable is compatible with most existing tools and cloud infrastructures, as well as emerging application development and deployment technologies such as Docker, AWS Elastic Container Service, Google Kubernetes, Microsoft Azure Container Service, Joyent Triton and Apache Mesos DC/OS.

Shippable Brings Declarative Model to DevOps

In general, DevOps is as much a process as it is a set of technologies. Typically embraced more aggressively by organizations building commercial applications that need to be regularly updated, many of the best practices associated with DevOps are now winding their way through the average enterprise.

The real issue is finding an approach to DevOps that naturally fits the organization as opposed to trying to make the organization as a whole magically transform itself overnight to fit someone else’s definition of what a particular DevOps process should look like.