Posted September 17, 2018
DevOps Meet Up: 6 Steps to Go Faster, Build Better and Avoid Disaster
Almost to the exact date, we hosted our second meet-up as part of the EuroSTAR TeamSTAR 2018 competition in the PorterShed, Galway! Last year, on September 7th we hosted a session on "The Magic Behind Faster API Development, Testing and Delivery with API Virtualization" as part of the 2017 TeamSTAR competition, and earlier this month, on September 6th we returned once again to host "DevOps: 6 Steps to Go Faster, Build Better and Avoid Disaster. However, this time we hosted a session with a twist - an interactive format which allowed the attendees to become part of the DevOps pipeline.
We kicked off the session with a 15 minute overview all about the world of DevOps and how to deploy quality software even faster with this methodology and then into a 45 minute interactive session as we had all attendees move between each stage of the DevOps pipeline (Plan, Build, Test, Release, Deploy, Monitor).
At each station, we had a member from the SmartBear team who facilitated conversation, encouraged collaboration and noted all feedback and discussion points onto their designated whiteboard in the following sections; Benefits, Challenges, Tools and Processes. Here is an overview from each station master:
[ PLAN ] Station Master: Aaron Fox
PLAN had a steady influx of visitors during the sessions. The persona’s differed from those curious as to what DevOps entailed to attendees with prior experience in the DevOps world. Some of the PLAN stage visitors were attempting to scale their Agile sprints to align with their DevOps implementation and one visitor was tasked with getting DevOps off the ground within their organisation. A highlight of some of the most insightful conversations we had at the PLAN station included;
- "We are trying to implement DevOps and we have the tools and expertise to do so. However we are facing buy in challenges from those who can influence".
- "We are currently operating in Agile with 4 week sprint cycles, we are attempting to move to DevOps but we can’t seem to align our Agile timelines with what is expected in DevOps."
- "Is there not considerable risk involved in trying to implement a DevOps structure given that so many components, teams and tools need to work in tandem."
In summary, almost everyone understood to some degree the uses DevOps and its advantages and could think of good use cases in their own workplaces. It was interesting to see that of the four categories ‘Challenges’ was focused on heavily. The overriding factor from the PLAN station influencing DevOps was the support within the workplace for such a shift and the willingness of people to let go of their current processes. Buy in is key!
[ BUILD ] Station Master: Ronan Trainor
For the BUILD station, we had a mix of experience among the people who came over to the station. One of the attendees worked in the planning step of DevOps, and therefore provided great insight into the steps prior to the BUILD stage. We also had other experienced DevOps evangelists who joined the BUILD station and gave opinions on the challenges faced every day - a common theme being data management with real-life examples used, such as having up to date schemas depending on the environments.
Our "benefits" section was undoubtedly the most filled out section of our white-board, and here is a snapshot of some of the benefits of DevOps discussed at the BUILD station;
- Regular release cycles
- DevOps preformed correctly is motivational to team members as the progress is visible
- Immediate ROI
- Resource relief
- Being able to demo product s to consumers early
Tools which were commonly used amongst visitors at the station included; Jenkins, JIRA, GoCD, Maven, Bamboo and Gitlab.
Similar to the plan station, having owner buy in and adopting organisational change was one of the main and common challenges faced. There was an overall consensus that adoption needed to be a business decision from VP level so that adoption would be companywide. Other challenges included; data management, configuration and having the available skilled resources and expertise in the field of DevOps.
[ TEST ] Station Master: Dermot Canniffe
At the TEST station, we had a mix of experience, amongst the people who visited the station. Two attendees were practicing automated testing, as part of a broader DevOps approach, with another group practicing manual testing but hoping to pivot to an automated test and/or DevOps mythology in the near future. We also had students from NUIG (our local University) who were interested in seeing what best practice would look like in a DevOps world.
We started with benefits, which focussed a lot on reliability ( the ability of automated tests to execute the same way each time, and it’s capacity to be executed frequently, to facilitate Continuous Integration/Deployment. We also discussed how automated DevOps testing can reduce costs by reducing LoE, and also how dependable, frequent test cycles permit a greater level of “Testscape” analysis, allowing you to chart quality progression or regression with greater accuracy.
When we moved on to challenges, we found it easier to come up with many more of these than with benefits, but reflected on the fact that the impact of each benefit we identified was actually very big, and outweighed the challenges considerably. We also noted that while there were many challenges, they were not necessarily show-stoppers – they were just stages that we overcome that make our DevOps process more robust and our QA more dependable.
In conclusion, many of the challenges focussed on culture and mindset, which was interesting – we’re in a world now where the tooling is comprehensive (we identified many test-oriented toolchains in our short session) to the point of not posing a technical challenge to adoption, and the processes (e.g. Regression testing, analysis, planning) are straightforward to understand and often already being implemented in some way . The real challenge is converting your organisation’s hearts and minds, and aid understanding of the benefits of DevOps.
[ RELEASE ] Station Master: Joe Joyce
There was a mixture of roles and levels of experience amongst the visitors to the RELEAE station. Our contributors included software development managers, senior engineers and junior developers. The more experienced visitors were keen to talk about how a DevOps approach to their release cycle and release management had resulted in better quality features and quicker time to roll-back from deployment issues. The more junior-level contributors were keen to pick the brains of the experienced engineers, as many of them were in the position of the first “DevOps” engineer in their organisations.
Key findings from the RELEASE stage included;
- Faster, incremental release cycles makes it easier to validate features quickly. This can save engineering teams from wasting time on product features that users aren’t actually that interested in.
- Education and an eagerness to learn are key for new engineers who are working in DevOps-style release management, as there are many new tools and technologies they’ll need to learn to release their software faster.
- Agile-style releases make disaster recovery a much easier process. By releasing features in an incremental, modular style, it’s easier to identify code that “breaks” the system.
To conclude, it was clear from our senior contributors that a DevOps-style release cycle makes sense and is indeed worthwhile, but that it is still a challenging process to implement this as a junior engineer.
[ DEPLOY ] Station Master: Damien Walsh
DEPLOY as one of the final stages to having the application go live, challenges became the focal point during the session where “Rollback” became a hot topic and whether fewer were done and if the right resources were available. We discussed money and being able to throw money to get more storage, RAM etc but is that a long-term fix and the money spent what will the ROI on that be regarding monetary value but also time savings.
However the benefits of an ROI means that we can become more reactive rather than proactive in a DevOps environment ensuring that as part of the sprint release we could add in a quick fix, quick enhancement feature etc. We talked about the t-shirt style way of labelling tasks and only have 1-2 large tasks in one cycle. When it came to Tools that came up were CircleCI, Trello and containerization and containerization is fast becoming the go to tooling and in particular Docker which allot of companies are continue to use as part of their deployment cycle.
The main findings from the DEPLOY station was that the group felt automating the DEPLOY stage had a knowledge transfer effect whereby people would forget how things operated however helped with the fast paced setting of DevOps environment. Only a few tools were used contrary to what I thought would be and time savings, cost and communication were key factors in ensuring that deployment was a success.
Overall, automating deployment resulted in good ROI overall. However, automation can lead to forgetting how the process works and how to fix/resolve issues when they do occur. The group agreed on challenges in this stage stemmed from communicating when a deployment would happen especially in a global application scenario, to then ensuring that it fitted into the culture of the company and its process. It’s this cultural and communication issues that can and will hold back as successful deployment in a continuous evolving DevOps process.
[ MONITOR ] Station Master: Noel Murphy
Everyone who visited the MONITOR station was working in a DevOps driven environment and based on the examples that I had listed under the benefits, challenges, tools and processes - they were very interested in knowing more about how SmartBear approaches monitoring for SwaggerHub. We touched on a number of topics from how our team is paged when there are issues out of hours to how we handle or rather avoid too much noise from our alerting! It was really interesting to discuss that some benefits can also be challenges as well for example "tuning" of the monitoring application so that it's not using up more resources than it should and killing the performance of your production servers.
Our conversations really focused on tools and aside from alerting you to a pending outage or other issues, monitoring tools can provide a good insight into situation awareness and help us make decisions in terms of our solutions capacity needs. Given the nature of using cloud infrastructure we can act quickly and safely to make these capacity changes with the minimal of impact to our customers.
In conclusion, we agreed that no matter what monitoring solution that you have in place the most important thing is that your monitoring is accurate. There is nothing worse than having to wade through a wall of false alerts - which people will eventually ignore until you end up with an outage that could have been preventable.
And there you have it, a summary of each station by the masters themselves! We received amazing feedback from attendees and how much they enjoyed the interactive approach - not just for the purpose of the meetup, but also for networking and collaboration. We loved being part of the EuroSTAR TeamSTAR competition once again this year, meeting and collaborating with all the attendees and of course being back in the PorterShed too.
Check out the slide-share here of the slides used from the event!