Ken Mugrage
My job is to teach the DevOps, I know I’ve succeeded when you realize that’s not a thing
Seattle, Washington, United States
Ken Mugrage is a Principal Technologist for the ThoughtWorks Office of the CTO. Ken has more than 30 years of experience in the IT industry, spending the last 13 at ThoughtWorks. During his entire career, Ken has focused on using technology to increase business effectiveness, as opposed to using the ‘latest cool thing’. Ken has been focused on Continuous Delivery and DevOps for most of the past decade, working with organizations all over the world, ranging from startups to Fortune 50 companies. He now uses this experience to teach others how to get better at building, testing and deploying software.
Topics
It's not Continuous Delivery if you can't deploy right now
People often say that they’re practicing continuous delivery, and then add something like “I can let the security team know any time” or “I just have to run the performance tests.” Ken Mugrage explains why you’re not done with your continuous delivery journey if you can’t push your software to production right now.
Some of the things covered in this talk:
- Organizational structure for enabling Continuous Delivery
- Continuous Integration as a prerequisite to Continuous Delivery.
- Using feature toggles and branch by abstraction to separate deploy from release
- Deployment methodologies which are well known terms (Canary, Dark Launching) but often not well implemented
- Things that should be part of the CD Pipeline such as security and performance tests
This is an opinionated, fast moving, high level talk. The goal of this talk is to make people think about the practices they could be doing to make their transition to DevOps and Continuous Delivery more effective.
DevOps isn't a job, a team, or a tool
When the term DevOps was created it was meant to represent a team developing and operating software together. A large part of that includes what the originators called “agile infrastructure”. While automation to enable this agile infrastructure is certainly important to DevOps, it was never meant to be the entire subject.
Unfortunately, many people think DevOps and automation are synonymous. This has lead to organizations creating “DevOps Engineer” positions to create that automation, and vendors creating “DevOps Tools” to sell to those engineers. Much like Agile isn’t just standing up for your meetings, DevOps isn’t just about automating server creation.
Some topics covered:
The origins of DevOps, and how you can apply its true principles to every part of your organization. It’s not one person’s job, it’s everyone’s responsibility.
Strategies for “selling” the organizational changes required to introduce a DevOps culture
How to take advantage of modern API based architectures to enable team autonomy
How to ensure security and compliance in a cloud native world
Attendees will take away an understanding of the cultural change required to convert to a DevOps culture and how to take advantage of modern architectures to help enable it.
All without creating a “DevOps Team”.
Can a DevOps culture help avoid burnout?
Clinical burnout has several causes. Chief among them are things like absence of fairness and a feeling of being ineffective in what we're doing.
In this talk I'll cover some of those well accepted causes of burnout and talk about how a culture of shared ownership and responsibility will help avoid many of them.
I'll also cover how adding new need to learn some fancy new tool and changing someone's title to "DevOps Engineer" is more likely to make it worse.
My hope is that people will understand and be able to recognize the causes of signs of burnout in themselves and their team. They will also understand how making positive changes to their working culture can help in some situations.
26 Feature Branches and other tales from the wild (ignite talk)
In the 9 years I’ve been working with customers on continuous delivery systems I’ve seen some, well, great learning opportunities. I'll make a bit of fun of things like no security testing, no compliance testing, feature branch nightmares, and a few other things.
This is a lighthearted ignite talk meant to be fun while teaching a little.
You only have to change one thing to "do the DevOps", everything.
10 or 15 years ago we would hear “agile doesn’t work” from lots of people. They had “used agile” on a project, and the project failed anyway. Most of the time a little investigation revealed that they didn’t really try it at all. Instead they worked much like they always had, just for two weeks at a time instead of several months.
The same thing is happening with people “doing DevOps”.
I strongly believe that the most important thing about a DevOps transition is the required changes in culture. But you can’t actually have self organized teams if you’re working on systems that are hard to build and deploy. You also can’t easily automate that build and deploy process if your architecture is hard to test.
In this talk I’ll point out several areas of focus when making the transition, and point out why it’s important that you change everything.
- Culture change - DevOps is about culture first and foremost. I’ll talk about some of the organizational structures which can help in creating a sharing culture where the teams and the technology can thrive.
- Evolutionary architecture - Adopting a technical architecture which is more testable and changeable is key to the ability to move fast. Taking advantage of microservices and platforms (such as PaaS) can help with this.
- Continuous Delivery - Continuous Delivery is more than just automating deployment. Making sure your software is going through things like security, performance and compliance testing in addition to “standard” tests. I’ll show ways to make sure your deployments are not only fast, but safe.
Technical habits for DevOps and Continuous Delivery
Moving to a DevOps culture and adopting continuous delivery has well known benefits. Unfortunately, those benefits are not realized by many organizations. One of the primary causes of this failure to meet expectations is a lack of solid fundamentals.
In this talk, attendees will learn about engineering practices which form a key foundation for building a DevOps culture, as well as effective continuous delivery pipelines. Like many things in software engineering, these practices are often dependent on one another in such a way that partial adoption isn’t enough.
Among the topics covered:
- Branching strategies
- Test driven development
- Running tests in parallel
- Pipeline ownership
- Trust but verify using automation
- Deploying incomplete code
This talk is primarily designed for people who would benefit from a holistic overview of the practices required for effective continuous delivery. There will be real world examples as well as resources to learn more about each area.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top