Open Credo

January 7, 2013 | Software Consultancy

The factors pushing many organisations towards Continuous Delivery with Infrastructure as Code and what’s next…

The practice of continuous integration in which build servers are used to build and perform testing of code is now widespread and mainstream.

While not all teams have adopted continuous integration effectively, its increasing adoption has led many to start to look for additional opportunities to improve the cost, quality and speed of delivery with which software targeted to meet business needs can be released into production environments.

Traditionally Continuous Integration addresses the question of “does the software build and pass our unit and integration test suites?”. This is often insufficient.

WRITTEN BY

Jonas Partner

Jonas Partner

The factors pushing many organisations towards Continuous Delivery with Infrastructure as Code and what’s next…

Continuous Integration does not always address other important questions such as:

  1. Do our unit and integration tests accurately reflect the requirements?
  2. Do we meet the non functional requirements such as performance and maintainability?
  3. Is this software something that the market wants?

Ensuring that developers have correctly understood the requirements has led to a focus on Behaviour Driven Development and automated acceptance testing. BDD seeks to allow executable tests to be captured in the language of those specifying the requirements. Automated acceptance tests as part of an automated build can discover divergence from expected behavior faster.

Since acceptance testing should be carried out in an environment that is much closer to production than that required for unit and integration testing, the desire to automate acceptance tests has also led to a need to be able to quickly and cost effectively create test environments which accurately reflect production environments.

The desire to monitor and test for non-functional requirements particularly such as performance has also lead to a need to be able to quickly spin up production like environments.
Testing software to see if it is something that the market wants is hard even with a high level of automation without actually releasing to at least a subset of the possible market. Ideas such as lean startup have added to pressure to be able to release quickly and often with a high degree of predictability.

Answering questions such as these has led to increasing interest in being able to release more often, with lower costs and with greater confidence in both the code being released and the infrastructure it is being released to. Even today most infrastructure is hand crafted by operations teams that may have some bash scripts to help. In recent years however there has been increasing interest in DevOps, which adopts practices from development groups and applies them to the process of building Infrastructure. Hearing phrases such as Infrastructure as Code and Test Driven Infrastructure has become commonplace. Practices such as these fit well with the desire for more frequent and predictable releases as part of Continuous Delivery initiatives however they are still not yet widely adopted.

At OpenCredo we have extensive experience using tools such as Chef, Puppet, JMeter, Sonar, Jenkins and Cucumber to help client organisations realise cost, quality and time to market benefits from Continuous Delivery implementations. We have experience of taking this approach to the point where a code commit results in the creation of a new environment populated with production data with automated functional and non functional tests then being executed. For organisations who have traditionally had cycles of weeks or months for new environments and performance testing the impact of this is hard to overstate.

Tools such as Chef and Puppet are critical to this and allow repeatable programmatic creation of environments. Many teams are now looking to embed their own DevOps practitioner into their own cross-functional teams. However finding the ideal DevOps practitioner with the right combination of development and operational skills is hard. In addition people are increasingly wondering how different all the environments being built with Puppet and Chef really are.

So while we at OpenCredo believe these tools are extremely important, we are also increasingly working with organisations who seeing the commonality in the per project platforms they are creating are looking to standardise by establishing a Platform as a Service initiative. The initiatives we have worked on to date take several forms, from technology vendors looking to create platforms, which make it easier to consume their technology as part of a platform to large organisations looking to achieve cost savings from the adoption of a standard platform. These platforms range from ground up efforts to those that build on open source offerings such as Cloud Foundry.

Continuous Delivery in summary

We expect to see continuing growth in the continuation of Continuous Delivery making direct use of Puppet and Chef.

We are also expecting the drivers of Continuous delivery to date to increasingly lead to the question “Why not PaaS?” being seriously asked.

Want to get in touch to talk about your project? Click here

 

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.

RETURN TO BLOG

SHARE

Twitter LinkedIn Facebook Email

SIMILAR POSTS

Blog