Agile2019 has ended

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

DevOps [clear filter]
Monday, August 5

10:45 EDT

DevOps > Automation, DevOps = Culture + Ownership + Empowerment (& Good Patterns) (Reneshan Moodley)

The three spheres of a DevOps adoption being Culture, Processes and Tools are fundamental to any organisation. The focus on tools often supersedes any work being done at the process levels and almost always, the culture aspect is 'ignored'. Through my years of helping teams adopt agile and eventually pursue DevOps, I've identified certain patterns that address the varying levels of change that are needed by a team pursuing Agile Ways of Work.
In this talk, I'll highlight the most important patterns that are needed along with suggestions to help embed these patterns. I will be using the DevOps radar (from SAFe) as a guidepost for patterns to get an organisation moving towards the promised land.
Whilst there isn't an 'endpoint' for a DevOps adoption, these patterns reflect milestones on a DevOps transformation roadmap and serve as a possible ‘quick start’.
NOTE: This is not. A SAFe pitch or SAFe sales workshop. The DevOps radar can be used, regardless of the presence of SAFe.

Learning Outcomes:
  • 1. Identify the three spheres of DevOps and assess where the most difficult work is to be found.
  • 2. Understand the patterns that can help and their suggested application.
  • 3. Understand the core skills/capabilities of a DevOps team.



Monday August 5, 2019 10:45 - 12:00 EDT
Chesapeake 10/11/12
Tuesday, August 6

09:00 EDT

Continuous Build and other DevOps anti-patterns, and how to overcome them (Thomas Stiehm)
Limited Capacity filling up

Software development is hard and poorly implemented or broken tools, techniques, and patterns just make it worse. Learn to spot DevOps anti-patterns and how to work your way back to a sane way of working.
Continuous Build is an anti-pattern that I have often seen where a team will have what they call Continuous Integration (CI) in place but it only builds the code, there are no unit tests or static analysis run. Certainly, this is better than not building but it leaves a lot of health check information on the table that is considered part of CI. Without this information, you can never really gain the confidence that your build is healthy. The whole goal of CI is to feel that your build is healthy so not tests and analysis means you aren’t doing CI.
Just like CI, other DevOps practices can be hard to understand, implement, and get right. Even with the best of intentions, we make mistakes or misinterpret the implementation of a technique. Learn how to spot common DevOps anti-patterns and how to correct them. These patterns include
1. Continuous Build - CI without tests isn’t CI
2. Turning unit tests off to build the release
3. Don’t automate that, it is my job
4. Different build process for developers and high environments
5. Different deployment process for developers, test environments and/or production
6. Not having a production-like environment to test in before production
7. Saving performance testing for the end of the release
8. Saving security testing for the end of the release
9. Never asking the users about the software
10. Only automating build and deployment, not testing
11. Not having retrospectives
12. Restricting retrospectives to only the development part of the process
13. Running analysis and never looking at or acting on the findings
14. Reduce coverage or static analysis gates to get a build to pass
We have all experienced a time where we wanted to believe we could make an anti-pattern work but it never does. It is better to learn how to spot these and how to correct them than it is to try to keep tweaking a broken process hoping this time it will be better.

Learning Outcomes:
  • How to spot common DevOps anti-patterns
  • How to correct DevOps anti-patterns when you see them
  • Learn how to figure out if what you are doing is stymied by an anti-pattern and how to rally your team around moving off that anti-pattern
  • Learn that motivation for anti-patterns and how to get people to change their minds about it


avatar for Thomas Stiehm

Thomas Stiehm

CTO, Coveros, Inc.
Tom has been developing applications and managing software development teams for over twenty years. As CTO of Coveros, he is responsible for the oversight of all technical projects and integrating new technologies and testing practices into software development projects. Recently... Read More →

Tuesday August 6, 2019 09:00 - 10:15 EDT
National Harbor 6/7

10:45 EDT

Dev???Ops: The Missing Middle of Security (Elizabeth Ayer)

If you thought it was difficult bringing the Ops and Dev teams to the same table, let’s talk about security! Often housed in a separate team, security experts have no incentive to ship software, with a mission solely to minimise risk.
This talk is a detailed case study of bringing security into DevOps. We’ll look at the challenges and tactics, from the suboptimal starting point of a highly regulated system with a history of negative media attention. It follows an Agile-aspiring Government IT team from the time when a deployable product was "finished" to when the application was first deployed many months later.
This talk is about humans and systems - in particular how groups often need to flex beyond the bounds of what either side considers reasonable, in order to get a job done. We’ll talk about structural challenges, human challenges, and ultimately how we managed to break through them.
There are no villains - everybody in this story is a hero, working relentlessly through obstacles of structure, time, law, and history. Come hear what finally made the difference, filling in the missing middle of DevSecOps.

Learning Outcomes:
  • Understand challenges of bringing Security into DevOps in the most challenging situations
  • Experience a detailed story of a team going from "Done" to "Deployed" - in a painful 9 months!
  • Consider the structural changes which didn't work and the human hacks that did
  • Come away with lessons for starting an initiative and where *not* to compromise
  • Develop a sympathy for the conditions of US government technology


avatar for Elizabeth Ayer

Elizabeth Ayer

Product Manager, 18F
Who are you ?I'm the product lady who had to retire her battle cry of "Shippit!" after too many people misunderstood the intent. They can't take "early and continuous delivery of valuable software" away from me, though!As a product team leader, I have tripped and recovered my way... Read More →

Tuesday August 6, 2019 10:45 - 12:00 EDT
Chesapeake 10/11/12
Wednesday, August 7

10:45 EDT

A Software Engineer's Guide to DevOps (Laurie Barth)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.

Are you new to DevOps and trying to familiarise yourself with the terminology and concepts? Then this talk is for you. In the talk I will cover the 101 of DevOps including terms and technologies. Join me as I talk about why DevOps is necessary and the current ecosystem supporting it.

Learning Outcomes:
- What is DevOps really?
- What problems is DevOps aiming to solve?
- Current tools and technologies
- Terminology and vocabulary of DevOps

avatar for Laurie Barth

Laurie Barth

Software Engineer, Ten Mile Square
Laurie is a software developer and consultant at Ten Mile Square Technologies. Depending on the day she can be found using any number of technologies from different languages to frameworks and other support tools. She loves meeting new people, so come up and say hi!

Wednesday August 7, 2019 10:45 - 12:00 EDT
National Harbor 6/7
Thursday, August 8

10:45 EDT

DevOps Patterns to Enable Success with Microservices (Richard Mills)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.

DevOps can help you dig out of the problem you created for yourself: you spent your lunch period reading the interwebs, drank the kool-aid, and decided to embrace the utopia of microservices to solve all your fragile legacy monolithic code issues and allow you to release small independent changes into production. What you didn't realize is that you've translated an early-lifecycle code architecture problem into a late-lifecycle release management and quality assessment nightmare.
This microservice thing has not provided the nirvana you expected. You ended up with a set of federated services that have hidden dependencies on each other. You have a bucket full of independently changing applications maintained by teams that don't talk to each other and hide behind their service APIs. You want to deploy changes to production, but you can't even figure out which versions work together in your test environments. You need a way to bring your teams closer, continuously integrate the services, deploy the integrated services into various environments, and test that your still-monolithic system works in pieces and as a whole. This is looking suspiciously like a DevOps problem. You discover that your DevOps pipeline is critical to your success.
Someone once said to me "if you are building microservices without DevOps, you've already failed." I've learned that the integration problems created by independent microservices require a high level of automation for build, deployment, testing, and release. You need to create an automated pipeline that works independently for the individual services, yet has enough global knowledge of the system to assess whether small local changes break other services. The pipeline needs to facilitate communication between teams and notify them BEFORE they hopelessly break the system. It needs to keep track of which versions of the services include the right fixes to mutually breaking changes so they can travel together toward production.
In this talk, I highlight the important things you need to succeed with microservices and avoid some of the common problems:
  • Patterns for individual pipelines that combine to assess a working system
  • Using dynamic, ephemeral environments for early cross-service testing BEFORE people break things
  • Determining how appropriate versioning can simplify releases
  • Establishing a branch/merge process to minimize integration problems
  • Determining the value of using containers vs. virtual machines for microservices
  • Enumerating the types of testing needed at different stages of the pipeline
Participants will leave with some new ideas on what they might be doing wrong in their current microservice-based project and/or anticipate what's going to go wrong if they are just getting started.

Learning Outcomes:
  • Avoid common release management and integration problems caused by microservices
  • Define DevOps pipeline steps to independently deliver changes to a federated system
  • Design the right tests at the right stages for your pipeline
  • Use cross-service testing to enforce interfaces
  • Determine and promote cohesive releases of microservices


avatar for Richard Mills

Richard Mills

DevOps Solution Architect, Coveros, Inc.
Richard Mills has more than 25 years of experience in software engineering with a concentration on pragmatic software process and tools. Rich has a specific focus in Agile development methods and is passionate about DevOps, Continuous Integration, and Continuous Delivery. As a DevOps... Read More →

Thursday August 8, 2019 10:45 - 12:00 EDT
Chesapeake A/B/C

14:00 EDT

Service Ownership @Slack (Holly Allen)

Last year the Slack development team and operations teams were living in different worlds. Development teams deployed to production over a hundred times a day, and a centralized operations team tried to fix things when they broke. The operations teams struggled to support systems they had not written. Heros and knowledge islands saved the day over and over. Post-incident postmortems were poorly attended and did not encourage learning.
Slowly, then quickly, all that changed. Slack moved to teams of empowered developers on-call, with embedded SREs, safer production deployments, and actionable alerts. Postmortems focus on learning, and meaningful analysis of incident patterns is done at all levels of the company.
In this talk you’ll hear all about the bumps and scrapes, triumphs and pitfalls of our journey from a centralized ops team to development teams that own the full lifecycle of their systems. It wasn’t easy, but it wasn’t impossible. Hopefully it will inspire you to try something radically different at your company too.

Learning Outcomes:
  • How to organize development organizations for higher reliability
  • How to create learning organizations that can adapt
  • How to think about making major organizational change


avatar for Holly Allen

Holly Allen

Head of Reliability, Slack

Thursday August 8, 2019 14:00 - 15:15 EDT
National Harbor 2