FOSDEM

The slides from my From Dev to DevOps talk at FOSDEM 2012 Brussels are up in Slideshare. The material is also in the Lanyrd page.

The conference was huge, I’ve heard that over 4000 people showed up this year, for this free (as in both software and beer) event, organized on several tracks. Not bad considering that the temperature was between -15 and -6C (5 and 23 Fahrenheit) and got a lot of snow.

I spoke on the main auditorium with capacity for 1400 people, there was plenty of space. Unfortunately (for me, but great for the other speakers and the organization) some other devrooms got filled quickly, and couldn’t get into the Configuration and Systems Management Devroom, which should have been really good as nobody left as I was waiting outside between talks 😦

A lot of care by the organization, including a note with a 24/7 phone number in case I got “lost/confused/arrested” (which makes me think it must have happened before), and a full commitment to promote belgian beer 😉

And thanks to the people that attended my talk and engaged through twitter, got great feedback and hints for improvements on the future of development and infrastructure automation!

Grand Place 360 panorama

From Dev to DevOps slides from ApacheCON NA Vancouver 2011

ApacheCON NA 2011The slides from my From Dev to DevOps talk at ApacheCON NA 2011 Vancouver. Thanks to all the attendees for coming!

The audio recording seems that it’s going to be uploaded to FeatherCast.

UPDATE: the Lanyrd official page is up too

The code for the Maven-Puppet module is avalable in GitHub, and I’ll write some posts about it in the coming weeks.

The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.

Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.

In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.

Vancouver harbour panorama

ApacheCON NA Vancouver 2011

ApacheCON NA 2011I’m in Vancouver for ApacheCON NA 2011, where I’ll be speaking on Friday 14:30 about DevOps, From Dev to DevOps, my take on DevOps for people like me interested in DevOps and automation coming from the dev side, and expanding the dev lifecycle all the way to deployment to production. I have previously posted the slides from a another event and will post the updated ones after the talk.

If you are at the conference, come over and say hi!

The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.

Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.

In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.

From Dev to DevOps slides from Agile Spain

Conferencia Agile Spain 2011Updated slides from my “From Dev to DevOps” presentation at the Agile Spain conference in Castellon on October 20th. Thanks to all the attendees for the questions and feedback!

Just some updates on Vagrant, VeeWee, Geppetto, and Puppet-Maven. Next stop, ApacheCON Vancouver!

UPDATE The video is also available (in Spanish) at the UJI web server as Flash and WMV.

From Dev to DevOps slides from Apache Barcamp Spain

Here are the slides from my “From Dev to DevOps” presentation at the Apache Barcamp Spain in Seville on October 8th. Not all that useful without the talking and hand waving 🙂

I’ll be presenting it too at the Agile Spain conference on Thursday, with new slides, and adding some more info on Vagrant, VeeWee, Geppetto, and Puppet-Maven, just ten days after, things evolve really fast! Then, on to present at ApacheCON in Vancouver.

I’ll hopefully find the time to publish here at some point, in the meantime, there’s a good summary about the tools, Setup your devops playground with Puppet, Vagrant & co by Arnaud Heritier.

New challenges from DevOps: development cycle for your infrastructure

One of the main ideas behind DevOps adoption is the concept of  “infrastructure as code”. Tools like Puppet or Chef allow you to programmatically define your infrastructure, the provisioning of your servers: what packages are installed, what is the content of files,…

If server provisioning is a key point in operations, then code management becomes key too once you start coding your servers. You need source control for your infrastructure, you need tags, versioning, dependencies between components,… You need development, testing, QA, release,… for your infrastructure!

Imagine a environment where you have some server stack running in production using Puppet, with a manifest that defines packages and files in that server, and many servers running the same configuration. That Puppet definition must be in source control.

Now a security fix or new version of package must be installed in all the servers, do you just want to change the manifest and push it out to all the running servers? doesn’t sound like a great idea, does it? Hey, we have been tuning development best practices over the years for use cases just like this one.

What you want to do is create a new branch where you can do that change, and test it in some server that is not in production, let’s call it development environment, original isn’t it?
The change works as expected, your app still works, great! now you can probably merge that branch of the Puppet manifests into trunk, with possibly other changes made by other people, that at some point you will want to test together, in a production-like environment, maybe with several servers in a cluster, load balancing, etc… and very importantly, with the next version of the application that is going to be deployed. You create a new tag and version to be able to identify it later and deploy to that environment, let’s call it QA or staging.

What all this cycle allows you to do is clearly define what is running in each environment, using versions, and easily find issues between deployments, using source control, being able to roll back to known working configuration if needed.

After all, if you deal with infrastructure as code you should use code development best practices, and you’ll get the same benefits.