The artist formerly known as Development and Operations
So, we've all heard of the word DevOps, we've all heard of the word FullStack developer. But what are you really? You might question yourselves every day whether or not you are working in one of those roles. Or do you prefer to call yourselves just an engineer?
What is DevOps
Within the DevOps model, the two teams formerly known as development (Engineers/Developers) and operations no longer work side by side. This collaboration might have worked quite well for a long time but the business requires more frequent releases and, probably you know this as well, better internal communication. Making software and then handing it off to someone else to deploy it for you is prone to errors. When this deployment fails, the operations team gives it back with the message that it didn't work etc... Do you recognize this pattern? It's a bit like the waterfall model where the water jumps back to the top of the mountain whenever a single rock feels like blocking everything.
With DevOps, development and operations teams are no longer siloed. Very often Quality Engineers are also no longer a separate team. Having all the technical stakeholders in the same team allows for very close collaboration and the range of skills those engineers develop can grow rapidly. Important in this practice is that your technology stack allows for such rapid movement and iteration. Bugs can easily be spotted on any platform and consistency is key for stability. The more this team can become independent and rely on their tooling to help them deliver value, the better for the team's velocity.
The main pillars that we are trying to learn about are rapid delivery, reliability, improved collaboration, and security. Performance and scale are also important but there's a whole separate track for that this year!
What we are looking for
For DrupalCon we are looking for a whole lot of best practices that improve your team at one or more of those pillars. In today's world, a lot of those objectives can be achieved with technology and very good communication.
Rapid delivery can be obtained by making sure you have a very good continuous integration and a continuous delivery processes or automation. This could mean that any change to your site is automatically tested and when approved in the process, can be automatically deployed.
Reliability can equally be achieved by a combination of continuous integration and continuous delivery. Add a whole lot of monitoring to the mix and we are able to measure reliability and improve based on these measurements.
Obviously your website also needs to scale, but it is not always easy to scale when your infrastructure is not as flexible to scale with your application. There is making your software capable to scale and there is easily scaling your infrastructure. In this track we're only interested in the latter since the first will be covered in the Performance and Scaling track. Having your infrastructure as code, and obviously the technologies to support that, facilitates your scaling process. Or even designing a server-less infrastructure!
Something new this year that we are looking for, is the addition of security. For a very long time, security was seen as a very separate process with audits and a lot of manual work. Automation and embedding the facilitation of security is critical for a DevOps team to succeed. With security, we mainly mean the access to those servers or services that host your application.
But the main vision and value from adopting the DevOps culture is all about better collaboration between different roles in the team so that we can increase the delivery of value.
Tell your story
Have you created tooling to improve any of the above? Have you created microservices or infrastructure that help deliver value rapidly? Do you have learnings from working in a team that does or does not incorporate the DevOps culture? We want to hear from you in Dublin. Tell your story by submitting a session to the DevOps Track.