DevOps: Delivery Model.

The ideas and principles guiding the DevOps concept are indeed noble. Bridging the gap between the development and operations arms of an organization is of immense benefit. It has been credited for the creation of dynamic, fortified, and functional systems, characterized by adaptability second to none, with a clearly stated agenda: the improvement of service delivery. Emphasizing collaboration and cooperation between the two often opposing groups is guaranteed to bolster quality of products, as each will be a result of an intricate blend of ingenious ideas. A marriage of operational and developmental concepts will, in many ways, ease the development of systems, leading to plausible SDLCs and the most effective of ALM policies.

Lets have a look at the continuous delivery work flow

A developer working on a Agile team. in a large project, having multiple teams developing different components of the software application you are building. Developer does his work, based on the user stories they and the team are working on. At the end of the day, He do a ‘private build’ of work to verify it builds and ‘deliver’ it to a team build server. Other team members also deliver their work. He ‘integrate’ work in the common build area and do an ‘Integration Build’.

Once the application is built, at the end of every Continuous Integration build, deliver it to the next stages in the application delivery lifecycle. Deliver it to the QA team for testing and then to the operations team (the Ops in DevOps) for delivery to the production system.

To test out that the builds coming out are ‘production-ready’ they should be delivered to a staging or test area which is production like..

Continuous Delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time.

When continuously delivering software, one is not only validating the functionality and performance of the software being delivered and the environments it is being delivered to, but also the process of deploying the software itself. Deployment of the software is not as simple as copying some binaries over FTP. It involves file transfers, to multiple locations on potentially a complex set of nodes, but also involves configuration changes – to OS, databases and middleware. It also involves an orchestration of steps. One cannot simply do deployment steps in a mechanical linear manner. Middleware processes may need to be restarted after configuration changes. Services may need to be stopped before file transfers and then restarted, all in a coordinated orchestrated manner. Hence, continuous delivery allows for these processes to be tested and refined to ensure that when it comes to the final deployment to production, it is not the first time the team is executing the process(es). They are tested and proven to work.

In the flowchart above the Automation Agent for the delivery process takes care of deploying the resources to similar environments once the necessary artifacts are provisioned.

Coming next is to learn about DevOps Capabilities and IBM's tool chain to realizes devOps.