Jonny Wooldridge, CTO, The Cambridge Satchel Company at the DevOps Enterprise Summit 2014
View video: https://www.youtube.com/watch?v=CzUTztwcc58
View Jonny Wooldridge's blog: http://www.enterprisedevops.com
Following 3.5 years building a DevOps capability and culture at M&S I will be condensing the experience down to 10 Enterprise DevOps tips that are relevant to companies of all sizes and complexities. Bringing start-up lean thinking to an enterprise was never going to be easy but the lessons learned are relevant to us all.
Keith Zalaznik from Deloitte Consulting shows how arming IT with the tools to automate and integrate their core disciplines, real-time DevOps has the opportunity to profoundly impact the IT shop—accelerating IT delivery, improving quality and better aligning IT with the business.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
from 0 to continuous delivery in 30 minutesAgileSparks
In this session we will explore the full continuous delivery cycle from check-in to production using set of popular tools. During the session the attendees will be introduced to a set of tools and practices that enable continuous delivery from the technical point of view.
eDevOps in HPSW from buzzword to realityAgileSparks
In recent years we see a major shift toward SaaS solutions. More and more HPSW customers prefer to consume products like Quality Center, Performance Center and Agile Project Management as a Service.
Meeting this increased demand for SaaS triggered a major shift within HP SW development groups and HP SaaS operations group to not only modernize our products and offering but also to modernized the way we develop, test, deploy and operate our software in a SaaS model by moving to DevOps.
In this session we will discuss how HPSW Dev and Ops joined forces to establish the right methodologies, processes and technologies to build a true DevOPs delivery model that is aligned across HP SW, starting with Agile Manager, our first true SaaS product and continuing with traditional products like Quality Center.
Today in SaaS for Agile Manager we have 4 farms located over 3 locations (3 regions – AMS, EMEA, APJ).
We have more than 120 customers and over 6000 of users login each day to our systems with over 1000 active tenants.
We have bi-weekly pushes and Quarterly major releases, comprehensive monitoring processes and extensive implementation of HP monitoring tools.
Over 4000 tickets handled by both Operations and R&D.
Why a DevOps approach is critical to achieve digital transformationAgileSparks
The Internet of Things, mobile, big data and social media have all contributed to the need for a digital transformation of the products and services that companies deliver. The main objective of DevOps is to tightly integrate development and operations to improve the velocity of launching both new and enhanced existing applications to market whilst meeting other essential criteria such as quality, security and efficiency. DevOps can be a key enabler to support the Digital Transformation journey towards the new era of a unified, consistent and channel neutral experience.
Alexis Gaches
Advisor within the DevOps Business unit, CA Technologies
CA
How We Do DevOps at Walmart: OneOps OSS Application Lifecycle Management Plat...WalmartLabs
Recently, Dr. Qingsong Zhang spoke at a Meetup about how Walmart is using DevOps.
Within this slide deck, you'll learn about our DataOps, DevOps and OneOps, an application lifecycle management (ALM), and open source DevOps platform for cloud which was developed by Walmart Labs.
Feel free to follow us on Twitter: @one_ops!
Contribute to One_Ops: www.oneops.com
Think that DevOps is just for product? Think again.
In this webinar, ITSM expert John Custy shows you how to apply DevOps principles to your IT org. This event is for anyone involved in the support and development of IT systems and services. The keys to higher-performing services are so simple, they might surprise you.
Watch the full webinar here: http://atlassian.com/help-desk/how-to-run-it-support-devops-way
Brought to you by JIRA Service Desk. Learn more: http://atlassian.com/service-desk
Keith Zalaznik from Deloitte Consulting shows how arming IT with the tools to automate and integrate their core disciplines, real-time DevOps has the opportunity to profoundly impact the IT shop—accelerating IT delivery, improving quality and better aligning IT with the business.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
from 0 to continuous delivery in 30 minutesAgileSparks
In this session we will explore the full continuous delivery cycle from check-in to production using set of popular tools. During the session the attendees will be introduced to a set of tools and practices that enable continuous delivery from the technical point of view.
eDevOps in HPSW from buzzword to realityAgileSparks
In recent years we see a major shift toward SaaS solutions. More and more HPSW customers prefer to consume products like Quality Center, Performance Center and Agile Project Management as a Service.
Meeting this increased demand for SaaS triggered a major shift within HP SW development groups and HP SaaS operations group to not only modernize our products and offering but also to modernized the way we develop, test, deploy and operate our software in a SaaS model by moving to DevOps.
In this session we will discuss how HPSW Dev and Ops joined forces to establish the right methodologies, processes and technologies to build a true DevOPs delivery model that is aligned across HP SW, starting with Agile Manager, our first true SaaS product and continuing with traditional products like Quality Center.
Today in SaaS for Agile Manager we have 4 farms located over 3 locations (3 regions – AMS, EMEA, APJ).
We have more than 120 customers and over 6000 of users login each day to our systems with over 1000 active tenants.
We have bi-weekly pushes and Quarterly major releases, comprehensive monitoring processes and extensive implementation of HP monitoring tools.
Over 4000 tickets handled by both Operations and R&D.
Why a DevOps approach is critical to achieve digital transformationAgileSparks
The Internet of Things, mobile, big data and social media have all contributed to the need for a digital transformation of the products and services that companies deliver. The main objective of DevOps is to tightly integrate development and operations to improve the velocity of launching both new and enhanced existing applications to market whilst meeting other essential criteria such as quality, security and efficiency. DevOps can be a key enabler to support the Digital Transformation journey towards the new era of a unified, consistent and channel neutral experience.
Alexis Gaches
Advisor within the DevOps Business unit, CA Technologies
CA
How We Do DevOps at Walmart: OneOps OSS Application Lifecycle Management Plat...WalmartLabs
Recently, Dr. Qingsong Zhang spoke at a Meetup about how Walmart is using DevOps.
Within this slide deck, you'll learn about our DataOps, DevOps and OneOps, an application lifecycle management (ALM), and open source DevOps platform for cloud which was developed by Walmart Labs.
Feel free to follow us on Twitter: @one_ops!
Contribute to One_Ops: www.oneops.com
Think that DevOps is just for product? Think again.
In this webinar, ITSM expert John Custy shows you how to apply DevOps principles to your IT org. This event is for anyone involved in the support and development of IT systems and services. The keys to higher-performing services are so simple, they might surprise you.
Watch the full webinar here: http://atlassian.com/help-desk/how-to-run-it-support-devops-way
Brought to you by JIRA Service Desk. Learn more: http://atlassian.com/service-desk
More and more organizations are turning to DevOps as a way of working together to improve the efficiency and quality of software delivery and start adding more value to the business. But what exactly is DevOps and what does it mean for you and your organization?
Join Microsoft Data Platform MVP Kendra Little to discover:
• What is DevOps and what benefits can it offer your organization?
• Who in your organization should be involved in DevOps?
• Why should your organization adopt DevOps?
• How can your organization start implementing DevOps?
DOES15 - Ernest Mueller - DevOps Transformations At National Instruments and...Gene Kim
Ernest Mueller, Lean Systems Manager, AlienVault
DevOps Transformations At National Instruments and Bazaarvoice (And Infosec!)
In this presentation, I’ll share the thrills and chills of the real-world successes and setbacks in culture and collaboration, speeding up software releases, embedding DevOps engineers into product teams, implementing agile processes with operations teams, integrating testing and information security into daily work, automation and its pitfalls, metrics and their weaponization, and more. I’ll also discuss how we integrated security objectives into all these initiatives.
Introduces DevOps; the cultural and professional phenomenon that is rocking the IT world. By encouraging better collaboration, communication and integration between development and operational teams, DevOps is enabling organizations to build, deploy and operate quality software faster.
A high level introduction to DevOps. Explains what it is, how popular DevOps has become, why DevOps is popular, how DevOps differs from traditional approaches and some next steps to implementation.
DevOps is the most heard buzzword at this moment and also the confusing one. For many people the term means automation or a new job role. The primary characteristic of DevOps culture is increased collaboration between the roles of development and operations. There are some important cultural shifts, within teams and at an organizational level that is required to support this collaboration. Even with the best tools, DevOps is just another buzzword if you don’t have the right culture. As an organization how can you adopt the culture required for DevOps? How to start with the new cultural transformation? Are you creating another silo for the team? Are you ready to embrace the change of mindset? In this talk I am going to focus on what are the changes you need to welcome DevOps culture to your organization and what sort of benefits you can extract by doing that. We will discuss the challenges and also the solutions for the problems.
The session will be suitable for everyone who want to start the DevOps journey as well as those who already started but want to validate if they are doing it right or wrong.
A DevOps Mario Developer Game Challenge with GRC (Governance, Risk & Compliance)
To stay compliant, secure, you need to go faster. You may wonder how is that possible? Governance, Risk & Security — generally a bottleneck in most of the enterprises for their DevOps transformation. Wait, you have more to that story.
As we step into the eleventh year of the term “DevOps”, it is now mainstream in most organizations. It makes into the Strategy & Board meetings, CIO presentations, press releases and success parties.
BMK shares his experience with Enterprise DevOps Adoption
In many organizations, agile development processes are driving the pursuit of faster software releases, which has spawned a set of new practices called DevOps. DevOps stresses communications and integration between development and operations, including continuous integration, continuous delivery, and rapid deployments. Because DevOps practices require confidence that changes made to the code base will function as expected. automated testing is an essential ingredient Join Jeff Payne as he discusses the unique challenges associated with integrating automated testing into continuous integration/continuous delivery (CI/CD) environments. Learn the internals of how CI/CD works, appropriate tooling, and test integration points. Find out howpto integrate your existing test automation frameworks into a DevOps environment and leave with roadmap for integrating test automation with continuous integration and delivery.
DOES14 - Stephen Elliot - IDC - Delivering DevOps Business Metrics that MatterGene Kim
Stephen Elliot, VP of IDC
DevOps is the modern way to deploy new IT capabilities that drive and deliver business results. This session will dive into the key metrics that large companies are using to gauge the success and measure results utilizing the DevOps discipline. The session will answer the following questions:
What are some of the key technology and business metrics that large organizations are using to measure and manage DevOps projects?
What are the critical success factors required when communicating with the business on Devops delivered projects?
What role do the security and compliance teams play in DevOps, and related metrics?
DevOps: A Culture Transformation, More than TechnologyCA Technologies
DevOps is not a new technology or a product. It's an approach or culture of SW development that seeks stability and performance at the same time that it speeds software deliveries to the business. We will discuss this cultural shift where development teams have to accept the feedback of operations teams and the operations team should be ready to accept frequent updates to the SW that it's running.
To learn more about DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
DevOps is an emerging name for the collection of techniques we are adopting to meet this challenge and close the gap. While the DevOps movement is relatively young, many of its approaches are rooted in existing best practices.
This presentation makes an argument for DevOps, and proposes a DevOps Infrastructure team to help implement tooling that brings Developers and Operations folks together.
These slides are from a recorded webcast available here: http://www.urbancode.com/html/resources/webinars/DevOps_ITs_Automation_Revolution.html
DOES14 - Scott Prugh - CSG - DevOps and Lean in Legacy EnvironmentsGene Kim
10 Techniques for Flow & Continuous Delivery
Startups are continually evangelizing DevOps to be able to reduce risk, hasten feedback and deploy 1000’s of times a day. But what about the rest of the world that comes from Waterfall, Mainframes, Long Release Cycles and Risk Aversion? Learn how one company went from 480 day lead times and 6 month releases to 3 month releases with high levels of automation and increased quality across disparate legacy environments. We will discuss how Optimizing People & Organizations, Increasing the Rate of Learning, Deploying Innovative Tools and Lean System Thinking can help large scale enterprises increase throughput while decreasing cost and risk.
What are the Cool Kids Doing With Continuous Delivery?CA Technologies
Building a solid application delivery tool chain is no easy task. The popularity of infrastructure configuration management tools like Puppet, Chef, Salt and others are a direct result of the explosion of virtual machines needing to be maintained, configured and provisioned. Learn how you can leverage these trends and combine infrastructure configuration and release automation to build an enterprise class continuous delivery solution for your business.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
Whether you are a Developer, QA or a IT
Operations personnel, with organizations adapting devops practices you need to skill up
with the latest and the greatest of the devops tools, relevant to you. And its not the same
basket of tools that dev and ops both opt for. This talk is about the essential devops skills
required to transform yourself to be a next gen devops professional. And this is based on
real data, a devops skills report 2016 (to be published soon) by Initcron Systems.
More and more organizations are turning to DevOps as a way of working together to improve the efficiency and quality of software delivery and start adding more value to the business. But what exactly is DevOps and what does it mean for you and your organization?
Join Microsoft Data Platform MVP Kendra Little to discover:
• What is DevOps and what benefits can it offer your organization?
• Who in your organization should be involved in DevOps?
• Why should your organization adopt DevOps?
• How can your organization start implementing DevOps?
DOES15 - Ernest Mueller - DevOps Transformations At National Instruments and...Gene Kim
Ernest Mueller, Lean Systems Manager, AlienVault
DevOps Transformations At National Instruments and Bazaarvoice (And Infosec!)
In this presentation, I’ll share the thrills and chills of the real-world successes and setbacks in culture and collaboration, speeding up software releases, embedding DevOps engineers into product teams, implementing agile processes with operations teams, integrating testing and information security into daily work, automation and its pitfalls, metrics and their weaponization, and more. I’ll also discuss how we integrated security objectives into all these initiatives.
Introduces DevOps; the cultural and professional phenomenon that is rocking the IT world. By encouraging better collaboration, communication and integration between development and operational teams, DevOps is enabling organizations to build, deploy and operate quality software faster.
A high level introduction to DevOps. Explains what it is, how popular DevOps has become, why DevOps is popular, how DevOps differs from traditional approaches and some next steps to implementation.
DevOps is the most heard buzzword at this moment and also the confusing one. For many people the term means automation or a new job role. The primary characteristic of DevOps culture is increased collaboration between the roles of development and operations. There are some important cultural shifts, within teams and at an organizational level that is required to support this collaboration. Even with the best tools, DevOps is just another buzzword if you don’t have the right culture. As an organization how can you adopt the culture required for DevOps? How to start with the new cultural transformation? Are you creating another silo for the team? Are you ready to embrace the change of mindset? In this talk I am going to focus on what are the changes you need to welcome DevOps culture to your organization and what sort of benefits you can extract by doing that. We will discuss the challenges and also the solutions for the problems.
The session will be suitable for everyone who want to start the DevOps journey as well as those who already started but want to validate if they are doing it right or wrong.
A DevOps Mario Developer Game Challenge with GRC (Governance, Risk & Compliance)
To stay compliant, secure, you need to go faster. You may wonder how is that possible? Governance, Risk & Security — generally a bottleneck in most of the enterprises for their DevOps transformation. Wait, you have more to that story.
As we step into the eleventh year of the term “DevOps”, it is now mainstream in most organizations. It makes into the Strategy & Board meetings, CIO presentations, press releases and success parties.
BMK shares his experience with Enterprise DevOps Adoption
In many organizations, agile development processes are driving the pursuit of faster software releases, which has spawned a set of new practices called DevOps. DevOps stresses communications and integration between development and operations, including continuous integration, continuous delivery, and rapid deployments. Because DevOps practices require confidence that changes made to the code base will function as expected. automated testing is an essential ingredient Join Jeff Payne as he discusses the unique challenges associated with integrating automated testing into continuous integration/continuous delivery (CI/CD) environments. Learn the internals of how CI/CD works, appropriate tooling, and test integration points. Find out howpto integrate your existing test automation frameworks into a DevOps environment and leave with roadmap for integrating test automation with continuous integration and delivery.
DOES14 - Stephen Elliot - IDC - Delivering DevOps Business Metrics that MatterGene Kim
Stephen Elliot, VP of IDC
DevOps is the modern way to deploy new IT capabilities that drive and deliver business results. This session will dive into the key metrics that large companies are using to gauge the success and measure results utilizing the DevOps discipline. The session will answer the following questions:
What are some of the key technology and business metrics that large organizations are using to measure and manage DevOps projects?
What are the critical success factors required when communicating with the business on Devops delivered projects?
What role do the security and compliance teams play in DevOps, and related metrics?
DevOps: A Culture Transformation, More than TechnologyCA Technologies
DevOps is not a new technology or a product. It's an approach or culture of SW development that seeks stability and performance at the same time that it speeds software deliveries to the business. We will discuss this cultural shift where development teams have to accept the feedback of operations teams and the operations team should be ready to accept frequent updates to the SW that it's running.
To learn more about DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
DevOps is an emerging name for the collection of techniques we are adopting to meet this challenge and close the gap. While the DevOps movement is relatively young, many of its approaches are rooted in existing best practices.
This presentation makes an argument for DevOps, and proposes a DevOps Infrastructure team to help implement tooling that brings Developers and Operations folks together.
These slides are from a recorded webcast available here: http://www.urbancode.com/html/resources/webinars/DevOps_ITs_Automation_Revolution.html
DOES14 - Scott Prugh - CSG - DevOps and Lean in Legacy EnvironmentsGene Kim
10 Techniques for Flow & Continuous Delivery
Startups are continually evangelizing DevOps to be able to reduce risk, hasten feedback and deploy 1000’s of times a day. But what about the rest of the world that comes from Waterfall, Mainframes, Long Release Cycles and Risk Aversion? Learn how one company went from 480 day lead times and 6 month releases to 3 month releases with high levels of automation and increased quality across disparate legacy environments. We will discuss how Optimizing People & Organizations, Increasing the Rate of Learning, Deploying Innovative Tools and Lean System Thinking can help large scale enterprises increase throughput while decreasing cost and risk.
What are the Cool Kids Doing With Continuous Delivery?CA Technologies
Building a solid application delivery tool chain is no easy task. The popularity of infrastructure configuration management tools like Puppet, Chef, Salt and others are a direct result of the explosion of virtual machines needing to be maintained, configured and provisioned. Learn how you can leverage these trends and combine infrastructure configuration and release automation to build an enterprise class continuous delivery solution for your business.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
Whether you are a Developer, QA or a IT
Operations personnel, with organizations adapting devops practices you need to skill up
with the latest and the greatest of the devops tools, relevant to you. And its not the same
basket of tools that dev and ops both opt for. This talk is about the essential devops skills
required to transform yourself to be a next gen devops professional. And this is based on
real data, a devops skills report 2016 (to be published soon) by Initcron Systems.
20141024 AgileDC 2014 Conf How much testing is enough for software that can c...Craeg Strong
Using tools like TDD and ATDD, Agile provides the means to be confident that your brand new software is well tested-- even for life critical situations such as criminal justice software. But hold on a minute! It is a rare mission critical system that is built completely from scratch. There are always legacy components your team didn't build or doesn't control. Maybe the previous contractor built it-- but now they are gone and it is your problem. How can you be certain that everything functions properly in such a situation? How much testing is enough? How can you know whether a system has been tested? These are the questions that standards such as CMMI and PMBOK seek to answer with traceability.
The debate about traceability has been raging for a long time, with passionate advocates on both sides of the argument. Projects following traditional waterfall methods, and projects that conform to PMBOK or CMMI standards often create and maintain a requirements traceability matrix, or RTM, a document that traces “shall” requirements to functional capabilities and testcases. Some Agilists argue that the RTM is rarely consulted in practice, so the significant efforts required to maintain such a document are “waste.” Others point out that agile practices such as TDD provide all the traceability that may be needed. This talk will explore the underlying reasons why traceability may be important and worthwhile in many Federal government contexts, and review exciting new technologies that may provide an “agile answer” to this conundrum.
ATAAS 2016 - Amol pradhan - Bridging the gap between business and technology ...Agile Testing Alliance
Bridging the gap between Business and Technology using Behaviour Driven Development (BDD) "Behaviour" is a more useful word than "test". BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing. - Dan North, Creator of BDD. Speaker will be sharing his personal experience of how Behaviour Driven Development (BDD) helped to build the right product through genuine collaboration between Business and Technology teams
Object-Oriented BDD w/ Cucumber by Matt van HornSolano Labs
Here are the slides that Matt van Horn from New Relic presented at last night's Automated Testing San Francisco meetup, hosted by Constant Contact. This presentation briefly covers continuous integration at New Relic, and then dives deeper into Object-Oriented BDD with Cucumber. We thank Matt for the great presentation.
Please feel free to connect with Matt on Github or Twitter:
github.com/mattvanhorn
or
@nycplayer
http://www.meetup.com/Automated-Testing-San-Francisco/
10 things about BDD, Cucumber and SpecFlow - Long Version 2016Seb Rose
SpecFlow is quite a recent addition to the software development toolbox. Sometimes it feels like we’re using a hammer to drive in a screw, so in this session we’ll explore what it’s good for and when to use it. We’ll also look at what problems it doesn’t help with and when not to use it.
As you might expect, I’m a huge fan of using SpecFlow, as part of a well thought out approach to Behaviour Driven Development (BDD) or Specification By Example (SBE). I’ve also seen the pain of organisations who have tried using SpecFlow from a pure test automation perspective, and this is one of the misapplications that we’ll talk about.
We’ll look at a further 9 specific, actionable recommendations for using SpecFlow well, including how to write maintainable executable specifications, organising large suites of specifications in an accessible way, and where SpecFlow fits into an Agile development process.
By the end of this session you’ll know enough to decide whether your problems are more like a screw or a nail – and whether SpecFlow is the right tool.
Impact Maps/Story Maps - liefern was wirklich zähltChristian Hassa
Presentation from: Tools 4 Agile Teams Wiesbaden, Sept 18 2015
Impact Maps und Story Maps: liefern was wirklich zählt
Häufig verfehlen Softwarelösungen die Erwartungen der Auftraggeber, weil dem Team nur zu entwickelnde Funktionen kommuniziert werden, nicht aber das eigentliche Problem und der zu erzielenden Nutzen.
Impact Maps und Story Maps bieten eine einfache und schnelle Visualisierung der Problemstellung und möglicher Lösungsoptionen, und unterstützen so die Zusammenarbeit zwischen Team und Kunde. Der Vortrag gibt eine Einführung in die beiden Methoden, und zeigt deren Kombination und praktische Anwendung.
Upcoming workshops and training 2017 (Certified Scrum Master, Certified Product Owner, Specification-By-Example, Product Owner Key Skills, Migrating to a Serverless Architecture, Font-End Entwicklung Angular, JavaScript und TypeScript, Agiles Requirements Engineering)
Scaffolding a legacy app with BDD scenarios using SpecFlow/Cucumber (BDD Lond...Gáspár Nagy
Do you remember your childhood when your mom or an older story teller pronounced the most interesting words in the world? “Once upon a time…” Let me be now your story teller, listen to my story about a legacy app, a painful problem, the search for the solution and the lucky outcome. No, no, this is not the story about a new green field project where everything is so clear. However, even in this story there is a master builder, who shows the developers how to scaffold the legacy app with BDD scenarios using SpecFlow or Cucumber and everything will be all right in the end. Let me tell you about different strategies, collaboration and testing patterns that can be followed in such a renovation-like situation. So, are you ready?... “Once upon a time there was a company where…” To be continued at my session
Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects?
Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD?
This talk will show you how to be successful even with the oldest legacy projects out there through the usage of Agile processes and tools like Impact Mapping, Feature Mapping, Example Workshop, Story and Spec BDDs.
It's nice to work on Green Fields projects. But most of us aren't that lucky! Most organisations have large legacy code bases to maintain. And the legacy applications, ugly as they are, are often what generates the revenue!
But legacy code bases are not easy to work with. Adding new features, or even fixing bugs, is slow and fraught with danger. Unexpected regressions are commonplace. Long testing cycles is the norm.
In this talk we will look at some strategies that can enable you to add new features to legacy systems faster and more reliably. We will examine where the hold-ups typically are, and what We will learn how to write cost-effective automated regression tests suites, and how to use unit testing as a way to document your legacy code base for future work, and improve its quality along the way!
Impact Mapping is a lightweight method for strategic planning in product and project development. Although seemingly simple and intuitive, many teams fail to get the most out of it because they jump to conclusions too quickly and skip over important discussions. Christian and Gojko will talk about how to avoid common pitfalls and present two games that can help you facilitate impact mapping easily, support innovative ideas and divergent thinking, and help your teams and clients make a big impact through software delivery.
Cross mobile testautomation mit Xamarin & SpecFlowChristian Hassa
Test automation can be implemented most efficiently as a by-product of Specification-By-Example (SbE). It combines acceptance criteria specification and acceptance test driven development (ATDD, BDD) to build automatically validated specifications of the system. The practice is well established in many teams for “traditional” enterprise application development (web clients, rich clients, services), and supported with a broad range of tools.
In mobile development, however, we seem to start over again with bare-bones test automation tool support that provokes post implementation test automation, which is costly and hard to maintain. Teams that had already successfully applied ATDD/BDD fall back into old habits when moving to mobile development. This is due to the lack of tool support and a lack of confidence that the principles that worked before can also be applied in mobile development.
Join Gaspar, Christian and Andreas for a brief introduction to BDD and Specification-By-Example. They’ll then show how it can be put into practice with SpecFlow and Calabash for a mobile app that is developed using Xamarin.
Enterprise Devops Presentation @ Magentys Seminar London May 15 2014Jwooldridge
Thanks to Liam and the crew from Magentys for arranging a fantastic evening of presentations on all things DevOps.
Attached is my presentation from the event on Enterprise Devops.
For those of you who missed it:
“Join the crowd of 100 industry leaders across the Retail, Finance and Digital sectors for an exciting evening of talks in London’s Tech City on DevOps. Enjoy networking with a chilled beer alongside the experts who are making DevOps work and those who want to make it work.
Whether you’re a corporate or start-up, DevOps should be a hot topic so listen to how the experts are achieving great things, hear their views on the trends and discuss the future of DevOps.”
Jonny
enterprisedevops.com
Software development (Dev) and IT operations (Ops) are the roots of the term "DevOps" (Ops). The term refers to a culture change that will enable the continuous delivery of high-quality software and reduce the development cycle. It is primarily distinguished by shared ownership, automated workflow, and quick feedback principles. As a result, all phases of the software development cycle, not just a few, must be understood by the team members.
Slides from "Taking an Holistic Approach to Product Quality"Peter Marshall
This is the base material used during a half day workshop at expoQA 17 June 2019. Peter Marshall runs over the necessary technical, organisational, and improvement practices required to deliver high quality software. Deep dives into Continuous delivery, devops, organisational structures, agile and digital transformation.
Agile Project Management: From Agile Teams to Agile Organizations - Steve Mer...Agile Montréal
Agile Project Management: From Agile Teams to Agile Organizations
We will present the tools and strategies for adopting agile project management practices that connect business, management and delivery teams. We propose a framework that maintains an executive focus on managing investment and risk, introduces enterprise-level agile product development lifecycle and separates project governance from operational delivery while loosely coupling these activities.
À propos de Steve Mercier
Steve est un professionnel du développement de produits logiciels, comptant plus de 20 ans d’expérience. Il a développé et mis en place des lignes de production logicielles assurant une meilleure efficacité de livraison, une adhésion croissante aux meilleures pratiques définies et une qualité accrue des produits entraînant la satisfaction des clients. Il applique les méthodes de travail Agile au quotidien depuis bientôt 10 ans. Il aime les défis techniques, apprécie être responsable de livrer, avec des gens de talents, en équipe, des produits qui comptent vraiment. Au fil des années il s'est spécialisé dans les champs suivants: Bonnes pratiques de développement de logiciel, Intégration et livraison continue, Lignes de production logicielles, Infrastructure gérée comme du code, Méthodes Agile et amélioration continue. Il oeuvre en ce moment comme gestionnaire d’une équipe de 15 DevOps bourrés de talent chez Lightspeed.
À propos de Jean-Paul Chauvet
President, Lightspeed
With over 20 years' experience as a marketing and sales executive in the technology sector, JP has been a key element in the continued growth of Lightspeed. By developing and leading Lightspeed's product strategy, go-to-market direction and taking a direct approach to engaging independent businesses, he has helped Lightspeed increase revenue, strengthen partner relations and achieve success month over month.
Manchester ITExpo Talk: DevOps large and small - Cambridge SatchelJwooldridge
ITExpo Manchester Slides on how to represent DevOps large and small, ie large corporate enterprise compared to startup with clean sheet of paper. How to approach Software Engineering with DevOps front and centre of team and technology strategy as developed by Jonny Wooldridge from Cambridge Satchel
From the the teams struggling with DevOps to experienced professionals trying to make a shift to DevOps, this presentation helps in how understanding how DevOps makes Deliveries faster and accurate
2i recently attended a DevOps Summit in London to learn more about how different companies have implemented DevOps. Read our overview to gain a better understanding of the DevOps operating model.
In Data Engineer’s Lunch #68, Will Angel, Technical Product Manager at Caribou Financial, will provide an introduction to DevOps practices and tooling including testing, deployment automation, logging, monitoring, and DevOps principles. Additionally, we will discuss some of the ways that DevOps for data engineering is different from conventional application development.
Accompanying Blog: Coming Soon!
Accompanying YouTube: https://youtu.be/eBtrOv_qLHQ
Sign Up For Our Newsletter: http://eepurl.com/grdMkn
Join Data Engineer’s Lunch Weekly at 12 PM EST Every Monday:
https://www.meetup.com/Data-Wranglers-DC/events/
Cassandra.Link:
https://cassandra.link/
Follow Us and Reach Us At:
Anant:
https://www.anant.us/
Awesome Cassandra:
https://github.com/Anant/awesome-cassandra
Email:
solutions@anant.us
LinkedIn:
https://www.linkedin.com/company/anant/
Twitter:
https://twitter.com/anantcorp
Eventbrite:
https://www.eventbrite.com/o/anant-1072927283
Facebook:
https://www.facebook.com/AnantCorp/
Join The Anant Team:
https://www.careers.anant.us
Benefits of Agile Software Development for Senior ManagementDavid Updike
This is a presentation to Senior and Executive Managers which is used to explain how Agile Software Development processes and practices benefit them, their organization and their customers.
Cutting Edge on Development Methodologies in ITAndrea Tino
A presentation encompassing Agile Methodologies and DevOps practices with the aim of providing an historical perspective and a broad overview of these topics.
Many entrepreneurs consider DevOps solutions useful for startups and technology companies. The reason behind this notion is the chief objective of DevOps implementation, which is to help companies build their culture or establish cloud-native roots. However, the reality is completely different! Best practices in DevOps are beneficial for all enterprises irrespective of their sizes.
Read the full article - https://www.silvertouch.com/blog/enterprise-devops-importance-and-key-benefits-you-need-to-know/
DOES SFO 2016 - Kaimar Karu - ITIL. You keep using that word. I don't think i...Gene Kim
Let’s get this straight. ITIL is not about implementing dozens of processes, or about establishing a CAB to review every change request, or about the never-ending story of creating a CMDB. The ITIL framework has been designed to help IT organizations to move from being a black box technology provider – often viewed as a disposable cost centre – to becoming a service provider, and a true partner for the rest of the business. We know – we own the framework.
Unless your customer can achieve their objectives with the technology you run, and can get assistance when needed, no-one cares whether your architecture is built on a monolith, uses microservices, or can brag about being serverless. Agile as a mind-set covers the whole value chain, but common practices are limited to development only. DevOps as a philosophy covers the whole value chain, but common practices are limited to the deployment-focused intersection of development and operations only. Understanding the organisation's strategy, developing the product strategy, and dealing with customer issues are expected to be taken care of by someone else, as if by magic. Because of this, DevOps faces a risk of becoming the largest local optimisation exercise ever undertaken for way too many organisations
In tens of thousands of companies around the world, ITIL has helped to develop an organizational capability that has provided them with a competitive advantage. More than three million people have been certified, and ten times as many trained over the years. Yet, we have all heard the horror stories, too. So what is it that separates a successful adoption of ITIL from an unsuccessful attempt at implementing the framework? What are the common problematic practices and anti-patterns we have seen in the wild, and what does the guidance in ITIL really say? How can you move from a broken approach to IT Service Management to one that delivers value. Can you still use ITIL in the DevOps world? Do you even need to? Or, perhaps, the questions is whether DevOps can survive (in the enterprise) without embracing the service mind-set.
DOES SFO 2016 - Daniel Perez - Doubling Down on ChatOps in the EnterpriseGene Kim
HPE's Research Development & Engineering team has been on a fast-tracked DevOps journey over the past couple of years.
During our DOES 2014 talk we shared our deployment of ElectricFlow as a highly available and centralized self-service solution that has enabled HPE developers to quickly onboard onto ElectricFlow for build/test/deployment pipelines in a repeatable and cost-effective way.
At DOES 2015 we expanded on our investments into a comprehensive monitoring, self-healing, and accelerated deployment strategy across all of our applications to further bridge our Dev and Ops gap with greater visibility into our environments and to accelerate our time-to-market with repeatable and fully automated deploys.
Join us this year as we continue in this journey with our biggest transformation yet: the proliferation of ChatOps within our organization. We will discuss the decisions that lead us to these investments, the key lessons we have learned, and share our various Hubot integrations and capabilities.
DOES SFO 2016 - Greg Maxey and Laurent Rochette - DSL at ScaleGene Kim
t last year’s DOES conference, we introduced the new Domain Specific Language (DSL) for Electric Flow and painted a vision for how it could revolutionize application release automation (ARA) for very large enterprise implementations.
We are pleased to share with you our experiences and learnings from such a large scale implementation in a financial services company that we’ve been working on this past year. This is a very large implementation—hundreds of ‘platforms’, each containing hundreds of application components each targeting hundreds of ‘device types’, that is, thousands of components distributed across tens of thousands of end points in data centers across the world.
Because of regulatory and quality concerns, complex multi-environment stage testing and promotion systems with clear separation of duties must be enforced. While Electric Flow provided the core functionality to achieve these goals, there was a considerable amount of customization required to support legacy applications, tools and processes. All of the custom work done by the Electric Cloud professional services teams was done in DSL, that is, source code first. Customizations are maintained in a source control system and applied to the various staging environments through automated script execution managed by Electric Flow. While the Electric Flow UI was not used to author content, it was used to verify implementation and provide a convenient ways for the client to monitor progress of their application delivery. The result was a highly maintainable and scalable implementation that could be customized and adjusted on a moment’s notice. Indeed, the project has been managed in a lean agile manner with three week sprints.
DOES SFO 2016 - Rich Jackson & Rosalind Radcliffe - The Mainframe DevOps Team...Gene Kim
This session will discuss the success story from Walmart on how they built a set of services on the mainframe to provide capabilities at a large scale for their distributed teams, as well as discuss the transformation required for mainframe teams to achieve this success.
DOES SFO 2016 - Greg Padak - Default to OpenGene Kim
Large enterprises have hierarchical organizations to define areas of responsibility and drive better accountability. Those structures often block cross-team interactions and knowledge sharing that slow innovation and agility. We will discuss strategies that use open platforms to drive meaningful development outcomes through collaboration and productivity across the enterprise.
DOES SFO 2016 - Michael Nygard - Tempo, Maneuverability, InitiativeGene Kim
Tempo. Most people are familiar with it in the musical sense. It’s the speed, cadence, rhythm that the music is played. It drives the music forward - and pulls it back. But there’s more to tempo than a musical beat. In war, like in business, tempo - the speed at which you can transition from one task to the next - is a critical component for victory.
No single person nor department owns tempo. Somebody can’t just shout, “I now control the tempo,” and take charge. If you operate at a faster tempo than your cycle time allows, then you’ll get thrashing. The rate of tempo emerges organically as companies move around that action loop of sensing, deciding and acting.
Tempo emerges from the convergence of architecture, infrastructure, organization, and mindset. All these things have to align to achieve tempo. None of them can be changed in isolation.
In this talk, we will look at different models for transforming an organization to high tempo and high performance. We'll see how that can get derailed and what to do about it.
DOES SFO 2016 - Alexa Alley - Value Stream MappingGene Kim
Value Stream Mapping can streamline development processes and workflows. This talk will cover how Hearst has done internal Value Stream Mapping workshops to improve team collaboration and release times.
In this talk, I will discuss Value Stream Mapping and how it has helped transform internal processes for businesses within Hearst to adopt a DevOps culture. I’ll walk through the successes and learning experiences we’ve gained by holding VSM sessions at different businesses, in varying verticals at Hearst. We will review real examples of workflows, release times, benefits to the contributors and business, and how the collaboration has helped teams. While there are great successes, I will also share where we saw room for improvement and how we continually make changes to bring the most value to our teams. The most important value is how these have helped to start building a DevOps mindset in a company of over 25,000 employees.
DOES SFO 2016 - Mark Imbriaco - Lessons From the Bleeding EdgeGene Kim
DevOps news is dominated by discussions about tools, and with good reason. It's not unusual for the amount of infrastructure-related code in a system to approach or even exceed the amount of code dedicated to the actual problem the system is solving, even in small systems. As our systems scale in size and complexity, we invest an ever increasing amount of resources into building solutions to help manage our our complex technical systems. And rightly so.
What's often overlooked, however, is the human component of our systems. All too often our approaches to tools, processes, and systems management attempt to remove humans rather than empower them.
I'll make the case that humans are not a source of entropy to be safeguarded against in our systems, but rather a fundamental source of resilience and even efficiency. We'll discuss ways that we can use this point of view to our advantage when constructing our systems to move faster without sacrificing safety. We'll look at things like tools and our interactions with them, team collaboration, and even organizational structure and policies.
We've had plenty of talks about building for web scale, cloud scale, and even planetary scale. Let's spend some time talking about designing for human scale.
DOES SFO 2016 - Topo Pal - DevOps at Capital OneGene Kim
In my previous years’ talks at DevOps Enterprise Summit, I spoke about starting and scaling of DevOps at Capital One; importance of Open Source, Open Technology and Innovations in DevOps.
This year, I will present Capital One’s journey of maturing in DevOps and Continuous Delivery. My presentation will cover our current areas of focus: Delivery Pipeline, Flow and Measurements. I will also share some of the problems we faced and what we did to solve them.
DOES SFO 2016 - Cornelia Davis - DevOps: Who Does What?Gene Kim
Within the IT organizational structures that have dominated the last several decades roles and responsibilities are fairly standardized. But with the dramatic changes that DevOps practices and supporting toolsets bring, many are left feeling a bit off balance - it’s no longer clear who is responsible for even things as “straight-forward” as development or operations.
In this talk I will take traditional roles that are distributed across fairly standard IT structures and sort them into a new organizational context. What is the role of the Enterprise Architect? Who does capacity planning and how? How can change management step out of the way all while still satisfying the requirements of safe deployments? How do agile teams interface with personnel responsible for maintaining legacy systems? I’ll leave the audience with a blueprint for a new organizational structure.
DOES SFO 2016 - Avan Mathur - Planning for Huge ScaleGene Kim
Installing one CI server or configuring a deployment pipeline for a specific application might be easy enough. However, as enterprises look to scale their DevOps adoption and optimize their software delivery practices across the organization (to support additional teams, product lines, application releases, processes and infrastructure) -- software delivery pipeline(s) need to scale to support enterprise workloads.
For some enterprises, this means having a pipeline that can withstand the velocity and throughput of thousands of product releases, supporting tens of thousands of developers and distributed teams, hundreds of thousands of infrastructure nodes, multitudes of inter-dependent application components, or millions of builds and test-cases.
This scale poses unique challenges and implications for your pipeline design. This talk covers best practices for analyzing and (re)designing your software delivery pipeline – regardless of your chosen tool-set or technologies. Obtain tips and tools for ensuring your pipelines and DevOps infrastructure have the right architecture and feature-set to support your software production as it scales, while also ensuring manageability, governance, security, and compliance.
Learn best practices for how to:
1) Plan for scale: how to project for the types of performance indicators/vectors you’d need to scale across.
2) How to design of your pipeline and supporting infrastructure and operations (such as data retention, artifact retrieval, monitoring, etc.).
3) Design your pipeline workflows and processes to allow reusability and standardization across the organization, while also enabling flexibility to support the needs of specific teams/apps.
4) Design your pipeline in a way that enables fast rollout- easy onboarding thousands of applications, across hundreds of teams
5) Incorporate security access controls, approval gates and compliance checks as part of your pipeline and have them standard across all releases
6) Ensure your architecture support HA, DR and business continuity.
As organizations invest in DevOps to release more frequently, there’s a need to treat the database tier as an integral part of your automated delivery pipeline – to build, test and deploy database changes just like any other part of your application.
However, databases (particularly RDBMS) are different from source code, and pose unique challenges to Continuous Delivery - especially in the context of deployments. Often, code changes require updating or migrating the database before the application can be deployed. A deployment method that works for installing a small database or a green-field application may not be suitable for industrial-scale databases. Updating the database can be more demanding than updating the app layer: database changes are more difficult to test, and rollbacks are harder. Furthermore, for organizations who strive to minimize service interruption to end users, database updates with no-downtime are a laborious operation.
Your DB stores the most mission-critical and sensitive data of your organization (transaction data, business data, user information, etc.). As you update your database, you’d want to ensure data integrity, ACID, data retention, and have a solid rollback strategy - in case things go wrong …
This talk covers strategies for database deployments and rollbacks:
• What are some patterns and best practices for reliably deploying databases as part of your CD pipeline?
• How do you safely rollback database code?
• How do you ensure data integrity?
• What are some best practices for handling advanced scenarios and backend processes, such as scheduled tasks, ETL routines, replication architecture, linked databases across distributed infrastructure, and more.
• How to handle legacy database, alongside more modern data management solutions?
DOES SFO 2016 - Marc Priolo - Are we there yet? Gene Kim
2 years ago at DOES14, I presented “Vision Versus Execution: Implementing Continuous Delivery”. I shared how we achieved a big Continuous Delivery win – increasing software test coverage and delivery velocity and efficiency.
Since then, we have been busy scaling DevOps, Continuous Delivery and Lean principles across teams and practices throughout Urban Science. This rollout included both a cultural aspect, as well as an implementation of a centralized, shared, self-service automation solution for our teams – enabling them to “opt-in” to an automated pipeline.
In this talk I will present anecdotes and learnings gathered through our experience over the past two years and discuss the challenges and the value of scaling DevOps across the organization.
DOES SFO 2016 - Steve Brodie - The Future of DevOps in the EnterpriseGene Kim
DevOps adoption is growing rapidly, especially in the enterprise. What started as a “keeping up with the unicorns” grassroots movement within more forward thinking companies, has matured to large, complex enterprises now often being on the forefront of DevOps innovation.
DOES SFO 2016 - Aimee Bechtle - Utilizing Distributed Dojos to Transform a Wo...Gene Kim
Aimee Bechtle of Capital One’s Card Technology Advanced Engineering team will share how they have utilized Distributed Dojos to transform to a workforce skilled in DevOpsSec, public cloud and automation. Their Distributed Dojo strategy was formed when they needed to quickly and efficiently meet the challenges of a large cloud migration but were limited by local resources. Reaching out to a prominent retail chain they learned how draw from their engineering talent to form short-term, highly focused delivery teams. These teams now work cohesively across multiple locations to solve the challenges introduced when migrating such a large-scale, complex infrastructure to the cloud. They will explain how within weeks several Dojo teams were formed and releasing automation that not only supported Card Technology’s DevOpsSec and cloud mission, but provided associates with new skills that could be proliferated throughout the company.
DOES SFO 2016 - Ray Krueger - Speed as a Prime DirectiveGene Kim
Speed as a Prime Directive
Ray Krueger, Vice President of Engineering, Hyatt Hotels Corporation
Hyatt is transforming into a technology company that delivers digital experiences in the Hospitality industry. We're applying Continuous Delivery in order to achieve our goals faster. In the process, we are simplifying and abstracting legacy environments and building a hospitality technology platform.
DOES SFO 2016 - Paula Thrasher & Kevin Stanley - Building Brilliant Teams Gene Kim
After an initial DevOps transformation as a company, we had to grapple with how to scale and grow the talent and workforce to build a NextGen DevOps-minded company of 18,000+ people. We have built a number of programs to expand awareness, encourage growth mindsets, and drive workforce development. We will share the different ways we are working to "Build Brilliant Teams" to drive our DevOps transformations.
DOES SFO 2016 - Kevina Finn-Braun & J. Paul Reed - Beyond the Retrospective: ...Gene Kim
At DOES15, we presented the work we'd done at Salesforce to take their SRE teams to the "blameless cloud." We worked with various roles in the SRE teams so they could start asking the right questions about failure, and through the postmortem and retrospective process, begin to make lasting changes in _how_ Salesforce worked with and remediated identified failures.
But DevOps espouses less siloed thinking and more shared responsibilities, so we found postmortems within the SRE organization weren't enough. As Salesforce was moving toward a model of "service ownership," teams along
the entire software delivery value stream needed to start to understand their roadblocks to remediation and what aspects of the complex system they worked in were impeding their ability to "own their service."
We'll discuss the second phase of our work in helping these operations _and product_ teams gain a deeper understanding of service ownership, and why
just "DevOps'ing it up" wasn't quite enough on its own to help. plus we'll introduce an expanded model from last year's talk that incorporates human factors and complexity theory. These additions helped prime the teams to more effectively grapple with the challenges facing them on the road to true service ownership.
DOES SFO 2016 - Kevina Finn-Braun & J. Paul Reed - Beyond the Retrospective: ...
DOES14 - Jonny Wooldridge - The Cambridge Satchel Company - 10 Enterprise Tips for DevOps Success
1. Software is eating the enterprise
10 DevOps tips to help you take control before it’s too late
Jonny Wooldridge, CTO
2. Me:
2014 CTO Board Advisor
Head of Web Engineering
Director of Platform Development
Lead Developer / Head of Development
Web Master / Lead Java Developer
2011
2007
2003
1999
3. Marks & Spencer
Founded 1884, 85,000 staff
£10.3 Bn group revenues
2011-2014 introduced DevOps to international omni-channel retailer
Marks & Spencer as part of a successful £150 Million retail re-platforming
project. The importance of DevOps now understood at
board level.
650 Member project team, 65 new or modified applications.
On time and on budget.
The control of the software delivery lifecycle via Devops principles
IMHO kept the programme on the rails.
4. Cambridge Satchel
Founded 2008, 120 Staff
£10M total revenues
£100M by 2017
Now back in start-up world at Cambridge Satchel but the enterprise
lessons are key to building a successful and relevant technology
strategy which has longevity and agility.
$20 Million index ventures investment - clean sheet with technology
online, in store, in manufacturing and in the warehouse.
Lessons learned in Enterprise DevOps applied everyday.
9. Over Communicate your plan
What are you aiming for and what value will it bring?
Paces within enterprise applications Software Factory / Tooling
Why invest in DevOps, BDD, Automation?
A very valid question whether large enterprise or start-up
10. Over Communicate your plan
Plan your attack and be prepared for the
ecolefvfeaeto mr.achine.
Make friends across the business. You have no time for
enemies. You will have to call in favours.
Keep it simple even when it’s hard. Simple metrics.
<< Show it working to bring it to life >>
Use Diagrams and keep in your back pocket.
You get noticed in an enterprise if you care. So care (a
lot).
11. Over Communicate your plan
and the
team
“It’s all about the code”
Application code, Test code, Configuration code, Script code,
infrastructure code, 3rd Party Binaries
12. Over Communicate your plan
High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Team Software
Agile/Lean
practices
Great
Software
Good
practices
Good
Software
Poor working
practices
Poor
Software
Bad working
practices
Bad
Software
13. Over Communicate your plan
High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
$$$
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
$$$$
$$
$ Understand the cost to the
organisation of slow releases
Integration test costs
Cost of rework
Cost of delay and hand off
Cost of building the wrong thing
Cost of not asking the right
question
15. “Let’s do DevOps” << Grass roots desire from IT
Energising
“Why can’t we release 10x a day” << Board
Directors
Define the pace of your apps.
“What the..” << Middle managers
Distracting
Scary – expectation setting required
18. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
API
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Not all applications should
be treated in the same
way
Understand the pace
layers of your apps and
governance needed
How good are the major
vendor Ecommerce and
Finance/ERP systems?
Define the pace of your applications
Front
End UI
Finance
Systems
Payment
Order
Mgt
Core
Ecomm
Digital
Asset
Cust.
Mgt
Apps
API
API
API
API
API
API
API
19. High
The team’s
level of agile
working
practices
(Agile/lean)
YouF owra envte troy tbhei nhge?re!
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Fight the right battles with
your legacy
Where you invest your $$
is critical. Invest in DevOps
where it matters.
Define the pace of your applications
DevOps without legacy is
easy.
Front
End UI
Finance
Systems
Payment
Order
Mgt
Core
Ecomm
Digital
Asset
Cust.
Mgt
Apps
20. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Moving existing legacy
apps to faster delivery is
hard
Don’t make the mistake
of over promising!
Trying to improve all of
your applications just
won’t be practical.
Define the pace of your applications
Really?
Legacy Zone
22. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Components have no
dependencies that require
testing in a shared test
environment with
corporate applications
Many corporate
dependencies that require
testing with each other
and co-ordination of data /
process
Kill dependencies at all cost
Legacy Zone
23. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Reduce your legacy and
create new capability
Reduce size and complexity
of slow moving applications
Kill dependencies at all cost
E.g. consider creating a
Front End separation layer
enabling parts to be
independently released
NEW
Legacy Zone
24. Kill dependencies at all cost
Great Book.
Everyone now wants to deploy a
‘minimum viable product’
Define ‘viable’ in an enterprise
25. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Many organisations want
to be lean and get value to
their customers quickly
Understand what is really a
viable MVP
Kill dependencies at all cost
A change considered fast is
now very slow as it needs
to be coordinated with a
corporate release.
Legacy Zone
NEW
26. Kill dependencies at all cost
Only when you have end to end visibility of
speed of delivery across your ecosystem will
you be able to define an MVP.
Product Owners need to understand the
dependencies to prioritise.
27. Kill dependencies at all cost
Understand ALL of your dependencies: Obsessively understand
and control your dependencies. It is your dependencies with other
applications, particularly corporate systems that will slow you
down. Try to avoid the dreaded corporate Integrated Test phase.
Decouple your applications & architecture: – create services and
separate the layers of your application wherever possible.
Decouple your people: Give your teams more responsibility end
to end and greater autonomy. Remove dependencies on other
teams wherever possible.
28. Kill dependencies at all cost
Integrate with 3rd parties carefully. Bad choices with 3rd
party integrations can kill your speed of deployment as you
can become dependent on their deployment cycles, which
ultimately slow your own.
Stubbing: Intelligent stubs can be a good solution but is hard
and requires a strategy on ownership.
Testing is easier with less dependencies: Test scenario
complexity is reduced, test data alignment is less onerous with
fewer external dependencies.
30. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
An example project: part 1
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
STEP 1: Start with good
intentions
In this example the team are aware of
DevOps and start automating
build/deploy/test and using Continuous
Integration. The Operations team are
involved early.
Enterprise Project
Methodology/Governance/Finance
promotes integrated test phases and big
bang deployment. The intention is to deploy
independently hence it’s position on the
grid.
The plan is to think about Continuous
Delivery later in the project
Don’t create new ‘legacy’
NEW
Legacy Zone
31. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
STEP 2: The inevitable
project pressures show up
An example project: part 2
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
The team is under pressure and functionality
is prioritised over keeping automated test
and deployment scripts updated. Ops team
not as engaged as they had been.
The team tried BDD but did not continue
with it as the value wasn’t being seen.
Project Manager requests a detailed plan for
all tasks until go-live.
Agility starts to slip. Technical debt increases.
Don’t create new ‘legacy’
NEW
Legacy Zone
32. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
STEP 3: Find corporate legacy
An example project: part 3
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
dependencies
The application was on track to be delivered
but new dependencies are found (e.g with
corporate reporting and finance systems or
corporate middleware)
The new application is now tied into a
corporate release cycle.
Importantly the application might now
always be tied into corporate release cycle
until the dependencies are broken (if that is
possible)
Don’t create new ‘legacy’
Legacy Zone
NEW
33. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Set the bar high for new
initiatives / programmes
When a new initiative comes along and a new
team is built to deliver it set the bar high with
DevOps operational requirements and ways of
working.
Encompass:
• Behaviour Driven Development
• Continuous Integration
• Continuous Delivery
• Full automation
• Robust configuration management
Don’t create new ‘legacy’
NEW
Legacy Zone
34. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Ensure your corporate
project methodology
encourages DevOps..
…else you’ll create legacy
every time
Don’t create new ‘legacy’
Legacy Zone
NEW How do you measure
success of your projects?
35. Don’t create new ‘legacy’
<< Make end-to-end process a deliverable >>: You need to find a way to
ensure that the full end to end process of delivering software is part of the project. If it is
not the teams will lose focus and potentially slip into traditional ways of working that are
more familiar.
Product Teams vs Project Teams: Product teams are far more likely to want the
end-to-end process to be fast, for the software to have low levels of technical debt and
be easily supportable.
Legacy ≠ old: Many teams, and perhaps the majority in an Enterprise (even those
using agile methods) are set up to deliver legacy. It might be functionally rich and value
creating legacy, but it will be difficult to move into continuous delivery.
Coaching and Mentors: It is crucial that help is on hand to show the teams what
good looks like and to keep them on track both from a team point of view and technology
37. DevOps is not just an IT problem
Project Methodology. A gated Waterfall based project
methodology will lead to a focus on dates not necessarily value
creation and customer satisfaction.
HR, recruitment and rewards - in the same way that Agile was
disruptive, DevOps is even more so as it affects the wider team and
end-to-end processes. Often organisational structures at a high level,
and the bonus and rewards received encourage silo thinking.
Finance & Procurement – funding allocation and total cost of
ownership. A better built app today is worth the investment but may
not get funding. Tool purchases can stall waiting on the procurement
process.
38. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Wrong 3rd Party
Suppliers
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Enterprise equilibrium
tends to push your
DevOps adoption
backwards
DevOps is not just an IT Problem
Make the wrong choice
and the forces may be
working against your goal
of faster delivery. Wrong technology
choice
Wrong
hiring
policy
Wrong contractual &
financial frameworks
Wrong team
objectives &
rewards
40. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
A shared DevOps capabilty
can speed-up other team’s
Cloud
Adoption
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
DevOps adoption
A shared capability to
assist environment
creation and tool setup
You are unique. Think for yourself
Oil the enterprise machine
by removing common
impediments
Automation
Ways of
Working
Shared
Tooling
41. You are unique. Think for yourself
High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
You’re going to have to
think for yourself.
? There are still a lot of
areas of enterprise
DevOps that still need to
be answered
? ? ✔
Keep an open mind and
innovate yourself
43. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Expensive Tooling won’t
move the needle on its own
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Wrapping entire legacy
applications in new
automation deployment
software isn’t the answer.
Don’t automate your legacy
processes!
Make your tools work for you
Legacy Zone
$$$
44. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
MULTIPLE DIGITAL
TOOLSETS
Multiple sets of tools need to co-exist
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
New Ways of working
dictate new flexible
connected tooling
..specifically don’t be tied
to your corporate toolset
Make your tools work for you
Embrace best of breed
Open Source and make
sure you don’t get tied to
a particular tool..
TRADITIONAL
TOOLSET
45. Make your tools work for you
<<New Digital Toolset >>: Create a decoupled toolset of best of
breed tools. You don’t need the same tools for all paces.
Don’t be held back by corporate toolset: Corporate tools generally
don’t cut it
Make your tools work for you: Don’t change the way you work
because you have a new tool. Make sure the tool works for you not
the other way around.
Embrace OpenSource where possible: but don’t rule out paid for
products if it makes sense.
47. Build a Software Factory
You wouldn’t manufacture any other product at scale with
ad-hoc methods and so little visibility and traceability
48. Build a Software Factory for control and visibility
Build a software factory, why?
Let developers focus on creativity – the creative aspects of
writing code, not how their code gets into environments for
testing
Connect your tooling to get value and increase visibility.
Network affect.
Don’t forget information security! Add them into your build
pipeline.
Get visibility of everything – visibility of every code commit,
every requirement, bug and release. Auditors will love you!
57. Build a Software Factory for control and visibility
Have insight into your offshore suppliers like never before
Have control of your offshore suppliers like never before
Software Delivery data and information in one place
58. MAKE YOUR PARTNERS USE YOUR FACTORY
Control the deliverables from your partners
Do you really understand who is working for you?
Do you know the quality of the development?
Maintain ownership of your delivery pipeline at all costs
Force all suppliers through your delivery pipe without
exception
Builds are created from your code repository and all 3rd Pary
binaries versioned and centrally stored.
Again, if you show you care, your partners will care.
60. Start Behaviour Driven Development Today
Absolute Game Changer in all companies I’ve introduced it
BDD is more than TDD as it engages the business – usually the
business switch off when talking tests
Keeps DevOps on track – forces the right kind of automation
Keeps artifact aligned with Code (Test code, Config, Test Data)
If you do nothing else today – read up on BDD.
62. Prepare to be the large Enterprise of tomorrow
..so as discussed earlier make the right choices
today with:
Technology
Hiring, Retention & Training
Contracts & Procurement
3rd Party Suppliers and Vendors.
Make the correct choices to keep
on the correct DevOps trajectory
63. High
The team’s
level of agile
working
practices
(Agile/lean)
Continuous
Delivery
Core
Ecomm
Low High Software
Level of Independently testable
and
deployable software
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Front
End UI
Finance
Systems
Payment
Digital
Asset
Cust.
Mgt
Apps
Cambridge Satchel
Focus on systems that will
be key to innovation
We will be here!
25% Custom, 75% SaaS
SaaS solutions where
possible for back office
Strategy to stay on high
alert for creation of any
new dependencies or Silos
Order
Mgt
64. Thanks for listening!
Thank you
Jonny.wooldridge@cambridgesatchel.com
My blog, these slides and other musings available at:
www.enterprisedevops.com / www.enterprisedevops.io
66. Here’s what I would like help on
If you’ve got the answers to any of these I’d love to hear
from you:
managing test data in complex environments where
systems need aligned data
Ensuring your Behaviour Driven Development scripts
(e.g. gherkin files) can be easily version managed
across multiple branches of code.
Out of the box DevOps Factories?
Editor's Notes
WebMaster – that really was DevOps optimised in terms of alignment – Dev & Ops.
Hard Devops.
650 Developers in multiple disparate locations – waterfall contracts. DevOps kept the project on the rails and honest.
At the time there was nowhere really to go. None of our suppliers had heard of DevOps, nobody in IT. We had to define what it meant and why it was important.
Project was iterative waterfall with outsourced and separate Development, Test, Support & Operations teams. No access to hardware. Not a particularly fertile ground for DevOps.
The In-house engineering team were at the frontier of large scale DevOps and learnt an awful lot along the way. Overcame much more than just technology challenges.
Every technology decision being made is now with a backdrop of DevOps and often the 10 tips in this deck.
To back this up – check out the definitino from the oxford dictionary.
Everything in my deck today I’m applying in some form within Cambridge Satchel.
Enterprises are backfilling years of technical debt, dysfunction and lack of control of IT processes.
Start-ups have the advantage of starting from a clean sheet.
Plan your attack: It may be boring but you need a plan. Define clear goals and explain the benefits of a DevOps approach in the enterprise. This might be required to get funding in the first place.
Keep it simple: There will be a lot of people who will not have even a basic understanding of the steps required to make great software or how team structure and ways of working are so critical. They may have had experience in the past of a bit of coding or might have some understanding of Ops but assume that they know nothing.
Show it working…: You can have all the Powerpoint presentations in the world describing your approach and the benefits it will bring but in an enterprise people won’t fully understand it until you can showcase the improvements in end to end process. Over communicate.
Use diagrams: People in the enterprise are less likely to get excited by the latest scripting platform, test automation tool or cloud service! That is until they realise what benefits it has for them or their team. Show it in pictures and compare and contrast old ways of working.
Be honest: In an enterprise this stuff is hard. Understand what you’re going after and be clear on outcomes.
On the spot – define what you do.
The majority of us come to work to support the creation of code
From working on several initiatives within enterprises large and small it is evident that the level of DevOps maturity is driven by two factors:
The Team
Does the team have the necessary skills, working behaviours and objectives to be able to deliver small increments of software regularly. Is the team the right team?
Encompasses people and process. I can only think in 2 dimensions – a great team will have great team processes
The Software
Is the software the team is working on / inherited / designing suitable for fast delivery and has automated Build/Test/Deploy scripts?
Most large scale ecommerce platforms were built before DevOps considerations were around.
– great technology with have great processes.
From working on several initiatives within enterprises large and small it is evident that the level of DevOps maturity is driven by two factors:
The Team
Does the team have the necessary skills, working behaviours and objectives to be able to deliver small increments of software regularly. Is the team the right team?
The Software
Is the software the team is working on / inherited / designing suitable for fast delivery and has automated Build/Test/Deploy scripts?
Most large scale ecommerce platforms were built before DevOps considerations were around.
You can’t tak an application Ecosystem and treat it all the same. Gartner had been thinking a long the same lines with their pace layers – take a look at it.
Here is a typical application landscape/ecosystem for an ecommerce company with physical products – the average retailer.
I struggled when I first went from start-up world to enterprise to understand why everyone wasn’t doing Continuous Integration and working in an agile way.
Very colourful – apologies for that but you can see my point here. Not all applications require or can accommodate the same rate of change:
Front – end – change quickly
Payment Systems –$10s Billion going through some retailers components per year.
Different applications, different paces: Don’t assume they can all be developed, tested and deployed at the same rate of change. If you assume this you’ll never succeed with Enterprise DevOps.
Different paces, different governance: Continuously delivered applications will require different governance models to corporate releases. Treat each release type differently.
Understand your path(s) to production: Define the path to production for all your apps and the dependencies between them. This will will help you understand your roadmap and enable you to start to communicate to stakeholders expected improvements.
In a large Enterprise there will already be 10s if not 100s of applications supporting the business that have been built, bought or evolved over time.
The way in which the application is delivered, the team that deliver it and the underlying technology they are working on will affect how frequently the application can be deployed
Back to the paces – let’s put some colour (literally on this)….
Many systems are difficult to release fast due to lack of test automation coverage (of all types). Some Core Ecommerce apps sold by the major vendors are too difficult to build, test and deploy to allow for fast test cycles and frequent releases.
You need to make a decision early on where you want to focus your energies.
Many legacy or corporate applications have been outsourced and might have a slow delivery cycle and governance model but this might be appropriate for the application in question.
Aim High: Aim to have continuously delivery capability for all your high priority applications.
HOWEVER, if there are reasons why you can’t or there are constraints, make sure you can continuously deliver your apps into lower environments.
Factors influencing how far you go with Continuous Delivery:
How many environments you have.
Suitability of software and the amount of automated tests.
How well you have control over the deployments made into those environments.
How many other teams are sharing the environment for their projects
As with most problems, breaking them up into small chunks makes it easier to deliver.
Focus on new applications and teams, and applications that are high risk or have a high level of business change
These application portfolios have multiple dependencies and the applications themselves were not designed from the outset to be decoupled from other systems.
Over time the systems have increased in technical debt and coupling.
Multimillion pounds to create new environments and setup with test data.
Rather than try to take an existing application and continuously deploy it, those parts of the application that will need to change frequently to be independently deployable.
As an example keep the majority of the application the same but create a Front End architecture that can be ‘published’ on demand without a major release of core services.
Many organisations want to be lean and get value to their customers quickly.
The functionality might be ok to deliver as MVP (as signed off by the product owner), but aspects of the architecture and some enterprise dependencies actually make the chosen functionality non-viable as an MVP.
The change that was considered small and fast is now very slow (and probably expensive) as it needs to be coordinated with a corporate release.
Leave a legacy. Don’t create it.
. The team isn’t (yet) aware of all of their dependencies with the other enterprise applications
How many people have new projects that you’ll be undertaking. Raise the bar high, do things differently. You have the advantage of widespread understanding and proof that DevOps makes a difference. What’s stopping you doing the right thing on greenfield projects?
It is often the case that a company’s project funding model and associated gated project methodology focuses too heavily on delivery of a project on time and budget.
The operational requirements of scripted build, deployment, testing, validation are often considered too late in the project lifecycle (once vendors and technology are chosen).
Some of the large vendor commerce platforms weren’t designedwith rapid deploys in mind.
Hosting partners – no access to code.
The reason being, the technology and staffing choices you make now will affect how you can scale in the afuture.
Choices that in the past might have been judged on a single project delivery are now judged on capability to deliver incrementally ongoing.
Most blogs and writing on DevOps makes the point that a DevOps team is an anti-pattern.
I just ignored that because I could see that in an enterprise it makes sense. Even in a start=up it could make sense.
In a start-up, or where the challenge is isolated to a few teams then this is correct.
Not an anti-pattern in my view, but happy to discuss afterwards
Bigger questions exist the deeper into legacy world you go
Things that have worked for one company may not work fully in another company due to all the different factors at play.
For example it won’t increase your level of automated test coverage or help you with your architectural dependencies
New ways of working require different toolinzg that most likely is new in your organisation
Had a one-on-one session with VP of product for large ALM vendor a couple of years ago – I wanted Multi-pace multi vendor propogation of builds, test, deploys in various integration environments to work in their toolset. Answer: You’ll have to wait 3 years for that…..
Another large Vendor rebrand all of their products ‘DevOps’ – ie a single aligned view of software engineering, yet they have silos in their own sales team. Would need to talk to 4 different people to get the end-to-end view.
Fight the ‘This is the corporate standard’ anti-pattern.
The corporate standard tools did not join up the DevOps journey.
Free the team to innovate – locked down environments stifling innovation. Teams on the phone repeating commands down the phone – skype was banned by the way at the time.
Link Best of Breed Tooling together
This is relevant to all technology including Saas platforms – Demandware.
Not a single one of these systems existed
Outsource your development, but keep the teams honest by making everybody come through your factory Machines.
3 year
You need to make a decision early on where you want to focus your energies.
Many legacy or corporate applications have been outsourced and might have a slow delivery cycle and governance model but this might be appropriate for the application in question.
Aim High: Aim to have continuously delivery capability for all your high priority applications.
HOWEVER, if there are reasons why you can’t or there are constraints, make sure you can continuously deliver your apps into lower environments.
Factors influencing how far you go with Continuous Delivery:
How many environments you have.
Suitability of software and the amount of automated tests.
How well you have control over the deployments made into those environments.
How many other teams are sharing the environment for their projects