Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Putting the Dev in DevOps: DevOps Days Rome Review

DZone's Guide to

Putting the Dev in DevOps: DevOps Days Rome Review

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Originally authored by Kit Corry.

I recently attended devopsdays Rome.  This was my first time at a devopsdays conference and I enjoyed the mix of talks and open spaces sessions.  It was obvious that the presenters and the attendees have felt the pain of trying to introduce continuous delivery in their organizations and were there to share stories and seek advice to help.

The theme for this conference was “Culture”.  If DevOps is a “culture thing”, then surely we need to involve both Dev and Ops.  The surprising part was that there did not seem to be anyone from the Dev side of things.  In fact, there were topics like “getting Dev to think in terms of DevOps”.  The goal being to entice developers to think about the infrastructure of their applications including the operational concerns such as: scalability, redundancy, performance, monitoring, and feedback.

Monitoring was a very big topic, being covered by some 70% of the talks.  For this crowd, Puppet, Chef, and CFEngine define configuration management.  But it stopped there. Adding all of the discussions about stacks, tools, and cloud together yields something that looks like PaaS.  It allows them to provision and configure machines or virtual machines to provide well-managed and monitored services on which applications can sit.  However, at that point, Dev has no skin in the game.

Application delivery is needed to get Dev thinking in terms of DevOps.  Specifically, if while developing application components, developers need to concern themselves with how their components will be deployed to an environment and in a state where they can deliver value.

uDeploy deploys complex, multi-component applications.  For example, a simple web site consists of a web component (WAR file) and a database component (DDL).  The web component’s deployment process could upload the WAR file and restart the container (Tomcat, WebSphere, IIS, WebLogic, etc.).  This process is of concern to developers since it defines the required resources (the container) and the way the component is delivered.

These ‘component processes’ can be designed in concert with development teams so for a new development project the correct process can be selected by the developers.

Application processes define how the application as a whole will be delivered.  Concerns over scalability, for example, can be addressed by modeling a process for delivering the web component to multiple application servers behind a load balancer.

Developers don’t have to be the ones creating these processes, but they should understand them and use them for deployments into lower development environments.

One more thing, the middleware can also be deployed with uDeploy.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of Eric Minick, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}