|Dan North – @tastapod – Website|
Once Ada Lovelace invented programming Jane Austen knew it wasn’t going to end well unless she invented Operations. She proposed DevOps in the early 19th century in a series of coded stories with titles like “Support and Supportability”.
DevOps is a synthesis of agile development practices—small releases, high automation, close collaboration—with the “keeping the lights on” rigour and discipline of the Operations Centre. For it to succeed we need to learn to treat Ops as equals to Dev rather than voiceless downstream consumers.
Dan North uses his deep technical and organisational knowledge to help CIOs, business and software teams to deliver quickly and successfully. He puts people first and finds simple, pragmatic solutions to business and technical problems, often using lean and agile techniques. With over twenty years of experience in IT, Dan is a frequent speaker at technology conferences worldwide. The originator of Behaviour-Driven Development (BDD) and Deliberate Discovery, Dan has published feature articles in numerous software and business publications, and contributed to The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends and 97 Things Every Programmer Should Know: Collective Wisdom from the Experts.
|Rachel Laycock – @rachellaycock|
Continuous Delivery is fairly easy to implement in a “two-pizza team”. But what about when you have to adopt the practice across 10s or 100s of teams with legacy infrastructure, governance and security concerns not to mention clashing cultural norms. Not so simple.
Continuous Delivery is not a tool or a single team practice. There are several factors to a successful implementation: organisational, process and architectural. Each one will require significant changes in your organisation. I’ll share with you the common pitfalls and anti-patterns in each of these areas, which will hinder your ability to deliver your features and products rapidly at scale.
Rachel is Head of Technology for North America at ThoughtWorks, and is based in New York. She has over 12 years of experience and uses her deep technical expertise to coach teams in Agile and Continuous Delivery practices. She is a member of the Technical Advisory Board to the CTO, which regularly produces the ThoughtWorks Technology Radar.
Open Space is an unconference event that enables attendees to share knowledge, create new learnings, and connect with one another. Each PIPELINE Open Space enables attendees to dive deeper into conference topics, share experiences, and ask questions of one another.
Our 2017 open spaces are:
Culture e.g. knowledge dissemination, team design, vision creation
A PIPELINE committee member and/or volunteer will be present to facilitate each Open Space session, but these sessions are for attendees, by attendees!
|Abraham Marín-Pérez – @abrahammarin – Website|
“Do you find constantly rebuilding things that don’t need rebuilding? If yes, this talk is for you. The way your codebase is structured impacts what you need to rebuild after each commit, therefore, the codebase needs to be re-architectured with the build pipeline in mind. Sometimes you’ll have many responsibilities packed in one module, so you rebuild all of them every time you change one. Or maybe you have a multi-tiered application and adding a feature implies modifying (and rebuilding) all tiers, with cascading effects. In this talk we’ll go over scenarios like this and others, showing how the code can be rewritten in a way that minimises unnecessary rebuilds. In the end, you’ll be equipped with a number of techniques that will help you manage your build pipeline.”
Abraham Marín-Pérez is a Java programmer working with Equal Experts, author, public speaker and Agile consultant. He works with other organisations and helps them achieve their objectives through a number of varying challenges, both technical and non-technical. He also helps run the London Java Community, and contributes as a Java Editor at InfoQ.
|Alastair Smith – @alastairs – Website|
“Software is eating the world, but few apps are useful without a database behind them too. As such, we want to ensure our database code is well-designed and tested. Test-Driven Development (TDD) is a good tool for software design, and as SPROCs are as much code as classes and methods, we can apply the same principles to unit test our database rather than integration test it via the app.
This talk will cover how to write unit tests for your database, which parts you should (and shouldn’t!) test, and how to run your tests automatically on a CI server, after which you will be able to write unit tests for your own SQL code and enjoy database development again!”
“You have moved to Continuous Delivery and are delivering features fast. Unfortunately, as you know, responsibility for features doesn’t end with hitting ‘deploy’, and when it comes to deciding how best to iterate on your work you are often unsure of which option could next provide the most impact.
Even with substantial tracking, it’s not simple understanding whether and how a feature has changed user behaviour. It’s not that you lack data, but rather that it is muddied by all the things that happened at the same time as the release – product offers, a big news event, other simultaneous feature releases, or even just the difference in behaviour you see in how your products are used on the weekend.
This was our experience. Fortunately the answer was in AB testing – treating feature releases like scientific experiments, withholding changes from a portion of the audience to understand the impact of the feature, and using methods heavy in statistics to determine the differences in behaviour between the two groups.
Learn how we have adopted AB testing methodologies to understand feature impact, automating the process with an in house tool which has enabled us to test at the speed and scale continuous delivery allows.”
Amy has been working in Digital at the Guardian in roles ranging from Data to Product Management and currently Software Development. Recently she led a project to improve the way teams test feature releases, creating a tool which is now widely used across the organisation to determine feature impact.
|Andrew Martin – @sublimino – Website|
“How can we secure ourselves against unknown vulnerabilities in the Internet’s most widely used applications and libraries? To understand this better we must understand how vulnerabilities are introduced and their impact on the systems they exploit.
This talk examines the anatomy of major vulnerabilities, demonstrates their applicability to containerised applications, and explores remediation with container native security tooling throughout the pipeline.
At the end of this session attendees will understand how to escape the constraints of a container, introduce or expand Continuous Security throughout their pipelines, and proactively identify signs of a breach across their infrastructure.”
Andrew is a DevOps Lead for the UK Government with a strong test-first engineering background gained developing and deploying high volume web applications. Proficient in application development and Unix systems architecture and maintenance, he is comfortable profiling and securing every tier of a bare metal or virtualized web stack, and has battle-hardened experience delivering containerised solutions to enterprise clients.
|Andy Nesling – @andynesling|
“This talk will cover the journey I went on with my team and the things we learned along the way. When we took on the system there were no tests, it couldn’t be built in house, our environments were hand crafted snowflakes and each production release was a fraught episode which often ran late into the night when it didn’t go as planned. The journey was made harder as the system was also managing and taking data from a fleet of state-full IoT devices in homes.
Just focussing on build, test and deploy and not delivering features was not an option, for a small company we had to keep delivering features to stay alive. This talk will cover what we discovered, sometimes the hard way, what we focussed on and how we negotiated with the business to balance feature delivery with improving how we could deliver. Over two years we went from manual error prone two monthly releases of a monolith to a fully automated build and test pipeline which allowed us to release business value into production multiple times a week, stress free, with automated rollback. As our delivery became more agile, we started to see our relentless focus on continuous improvement change how the whole company prioritised work and features.”
Andy is a technical team lead at Dyson, helping to expand its IoT platform for the next generation of connected products. He has been leading connected product development teams for over 12 years, in roles ranging from development to test and product ownership. Andy is an evangelist for lean software development, Continuous Delivery and its application to the often waterfall world of connected product development.
|Steve Smith – @agilestevesmith – Website|
“Continuous Delivery is hard. The breadth and depth of recommended technology and organisational improvements, the smorgasbord of available tools, and the specific circumstances and constraints of your organisation create a huge challenge. Difficult decisions must be made, every single day:
– Should we try to improve stability or speed next?
These decisions occur in uncertain conditions, and if you make a mistake you can easily lose the alignment between individuals, teams and departments you need for continuous delivery to be successful.
We can reduce uncertainty and make better decisions by measuring the stability and speed of the release process, the build process and the codebase. These indicators of continuous delivery provide quantitative data on the impact of your changes, and pinpoint where the conversations need to happen so you can learn what’s working and what isn’t.
In this session, I will show how measuring stability and speed can power a successful adoption of continuous delivery in an organisation of any size. This is a deep dive into the latest thinking on continuous delivery, backed up by long-term case studies in private and public sector organisations”
Steve Smith is a Continuous Delivery consultant at Always Agile Consulting Ltd. He has been helping organisations adopt Continuous Delivery since 2007, and has overseen large-scale transformation programmes for up to 60 teams at a time. Steve is the author of “Measuring Continuous Delivery”, a co-author of “Build Quality In”, and a co-organiser of the annual PIPELINE conference.
Steve is stepping in on behalf of Dave Farley, who unfortunately cannot attend due to illness.
|Gareth Rushgrove – @garethr – Website|
“Can you adopt Continuous Delivery in the world of packaged enterprise software? What if software delivery is a pull model rather than push? You have 1000s of users all moving at their own pace? This talk will explore the practices of Continuous Delivery for quarterly, rather than daily, releases.
Most discussions of Continuous Delivery make the assumption that updates can be pushed out directly to consumers, or that everyone uses the same software-as-a-service based user interface which can be updated once for everyone. What about the cases where those things aren’t true? Where users pull a new version of the software when they choose to do so rather than when you ship it. What does continuous delivery mean in the realm of packaged enterprise software?
This talk will touch on:
* The role of versioning when shipping packaged software
The main take away from this talk will be that the practices of Continuous Delivery are still relevant and useful even when continuous is actually quite a lot slower.”
Gareth Rushgrove is a senior software engineer at Puppet. He works remotely from Cambridge, UK, building interesting tools for people to better manage infrastructure. Previously he worked for the UK Government Digital Service focused on infrastructure, operations and information security. When not working he can be found writing the Devops Weekly newsletter or hacking on software in new-fangled programming languages.
|John Clapham – @johnc_bristol – Website|
“It appears we have the formula for great engineering teams nailed; cross functional, T-shaped, pizza sized and manifesto enabled. Teams live in tension between their own output and contribution to the wider organisation, is spinning up a team in a continuous delivery environment any different?
The objective of this talk is to explore what you can do (regardless of your role) to improve your team and assist it’s continuous delivery capability. We consider design factors for teams, starting with what, if anything, is different about a continuous delivery team. We then look at common factors underpinning high performing teams, including environment, engagement and psychological safety.”
John Clapham is an independent coach, trainer and consultant. Founder of Cotelic, he specialises in DevOps and Agile, helping teams to build great products, and organisations to become more effective, productive and enjoyable to work in. His broad experience in software development ranges from start-up to enterprise scale, formed in the publishing, telecommunications, commerce, defense and public sector arenas.
|Leena SN – @leenasn – Website|
“Introducing Continuous Delivery practices to a team in trouble can be daunting. Where do you start ? What do you do first ? Which battle do you pick first ?
I’ll share my experience of guiding a team to achieve a higher degree of delivery maturity. This is a journey from a troublesome, struggling start of chaotic manual deployments, merge hell, regular production roll backs and lost code, to deliver a single commit to trunk automatically and reliably, under an hour, many times a day.
I’ll introduce the few simple practices that I’ve used successfully again and again, to introduce CD practices such as monitoring, build automation and test automation gradually, instead of going all in at first.
I’ll also show you how we leveraged the good practices that already existed in the team. Learn how each simple practice improves your team just a little bit more.
You’ll start to see that it isn’t daunting at all, and start delivering with joy.
You’ll find this useful if you are attempting to introduce Continuous Delivery practices, to a team or an organisation and finding it just a bit difficult. You’ll walk away with at least one improvement you can implement tomorrow.”
Leena is Head of Engineering @ Multunus, Bangalore with 15+ years experience in the industry. A Pragmatic & Passionate Programmer, Lean Thinker, Extreme Programming Evangelist, hooked into Continuous Delivery and a mother of two Lovely Angels.
|Mike Long – @meekrosoft – Website|
“A lot of software development falls naturally into the Continuous Delivery mindset, where any potential fix should be done on master and customers can naturally take the latest version of the software. We believe this is the the ideal approach to software development; it results in reduced cycle times, less work in progress, fewer queues and rework, and reduced testing costs.
However, not all software falls into this category. Some industries require that a given release be supported for decades. Some industries require that algorithms do not change, even for the better. But of course, any bugs must be fixed. Some industries require that any software that is qualified has a complete audit trail.
This presentation will share our experience in doing Continuous Delivery in the industrial embedded software world. It will describe how we can do component-based development for multi-product configurations, how to create a release from any version of our software and how we make sure we can maintain any software we have released to a customer.
It will cover version-control strategy, a binary artifact management approach, together with a build and dependency management solution that addresses this.”
Mike is a Partner at Praqma, a Continuous Delivery consulting company based in Scandinavia. He has over 13 years of experience delivering software in various cultures and industries. He helps organize several community events and conferences, including CoDe Academy which teaches Continuous Delivery to university students. Mike is a trustee on the cyber-dojo foundation.
|Pierre Vincent – @pierrevincent – Website|
“Independent changes and independent deployments are a great way to achieve Continuous Delivery with minimum disruption. Unfortunately as systems become less coupled and communicate over APIs or message queues, interactions become easier to break.
Consumer-Driven Contracts testing brings an alternative integration testing approach for distributed systems, relying less on live-like integration environments and more on making interactions explicit and quickly verifiable.
This talk will cover how we made CDCs part of its pipeline and how it improved confidence and collaboration between teams when designing APIs.”
Pierre is a Technical Team Lead based in Cork, Ireland. In 9 years of experience in building Internal Communications software at Newsweaver, he has transitioned from scary quarterly release cycles to Continuous Delivery. He is very passionate about enabling Teams to build the right thing by releasing less but sooner, to get early feedback and challenge assumptions.
|Robin Weston – @robinweston – Website|
“Serverless architectures have been touted as the next evolution of cloud-hosted software. Indeed, the promise of resiliency and scalability without the need for infrastructure management sounds too good to be true!
But how well do serverless architectures play with the patterns and practises of continuous delivery? Do they help or hinder us in our goal of delivering frequent and low risk software changes to production? What are the trade-offs to weigh up when considering using a serverless architecture on your next project?
This presentation will give a brief initial introduction to the world of serverless architectures. We’ll then look at their benefits and drawbacks, with a particular focus on our recent experiences building and operating a production AWS Lambda and API Gateway system. We’ll also look at the ever-evolving tooling and service ecosystems, and make some suggestions regarding how to start safely dipping your toes in the serverless waters.”
Robin has worked in technology for over 10 years and has been at ThoughtWorks since 2014. He cares passionately about helping deliver value to clients through simple, effective software. Away from work he spends his time running long distances for no particular reason, planning murder mystery treasure hunts and continually pinching himself to check that Leicester City really did win the Premier League.