Neal Ford

Continuous Delivery Workshop, part 1 of 3: Deployment Pipelines

8:30 AM MDT

The first part of the Continuous Delivery workshop covers the differences between continuous integration, continuous deployment, and continuous delivery). It also introduces the deployment pipeline_, along with usage, patterns, and anti-patterns. This part concludes with some applied engineering principles.

Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

The first part of the workshop describes the technical differences between related topics such as continuous integration, continuous deployment, and continuous delivery. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization's value stream for delivering software. I discuss the various stages, how triggering works, patterns and anti-patterns, and how to pragmatically determine what “production ready” means. This session also covers some agile principles espoused by the Continuous Delivery book, including new perspectives on things like developer workstations and configuration management.

Continuous Delivery Workshop, part 2 of 3: Testing, Synergistic Practices, and Deployment

10:30 AM MDT

Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.

Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant, including the audience and engineering practices around different types of tests. I also cover some best practices around testing, including testing ratios, code coverage, and other topics. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Generally, I talk about building synergistic engineering practices that complement rather than conflict one another. In particular, I discuss why feature branching harms three other engineering practices and describe alternatives. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.

Continuous Delivery Workshop, part 3 of 3: Infrastructure and Data

1:00 PM MDT

Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process.

Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure using tools like Puppet and Chef. I also discuss the explosion of tool alternatives in this space, and cover some current-day best practices. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process. This includes database migrations, strategies for enhancing collaboration between application development and data, and database refactoring techniques.

Hypothesis/Data Driven Development using Feature Toggles

4:30 PM MDT

Hypothesis and data driven development ties together current thinking about requirements, Continuous Delivery, DevOps, modern architecture, and engineering techniques to help rethink building software.

Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development. This talk also demonstrates how to undertake major architectural restructuring with zero regression failures by relying on data and the scientific method.

Building Evolutionary Architectures Workshop

9:00 AM MDT

This workshop highlights the ideas from the forthcoming Building Evolutionary Architectures, showing how to build architectures that evolve gracefully over time.

An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

Outline:

• Architecture Dimensions
• Engineering Incremental change
• Architectural Characteristics
• Exercise: determine appropriate characteristics
• Identifying Architectural Patterns
• Exercise: components and patterns
• Identifying Fitness Functions
• Exercise: determining fitness functions
• Retrofitting Existing Architectures
• Building Evolvable Architectures

Building Evolutionary Architectures Workshop

11:00 AM MDT

This workshop highlights the ideas from the forthcoming Building Evolutionary Architectures, showing how to build architectures that evolve gracefully over time.

An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

Outline:

• Architecture Dimensions
• Engineering Incremental change
• Architectural Characteristics
• Exercise: determine appropriate characteristics
• Identifying Architectural Patterns
• Exercise: components and patterns
• Identifying Fitness Functions
• Exercise: determining fitness functions
• Retrofitting Existing Architectures
• Building Evolvable Architectures

Clojure Workshop

1:30 PM MDT

In an increasingly crowded field of languages, Clojure stands alone. It is a dynamic, functional, high performance dialect of Lisp that runs on both the JVM and CLR. The creator cast aside assumptions from both the Lisp and Java communities to create a remarkable language implementation.

This workshop introduces Clojure to Java developers who might not have seen a Lisp and don’t yet understand why that’s such an advantage. I introduce the language syntax (what little there is of it), cover interoperability with Java, macros, mutlti-methods, and more. I also cover the functional aspects of Clojure, showing its powerful immutable data structures, working with threads and concurrency, and sequences. Beyond just showing syntax, I also show how to build real applications in Clojure, and give you a chance to do the same. Attending this workshop shows enough to pique your interest and show why many of the people who were interested in Java in 1996 are interested in Clojure now.

Clojure Workshop

3:15 PM MDT

In an increasingly crowded field of languages, Clojure stands alone. It is a dynamic, functional, high performance dialect of Lisp that runs on both the JVM and CLR. The creator cast aside assumptions from both the Lisp and Java communities to create a remarkable language implementation.

This workshop introduces Clojure to Java developers who might not have seen a Lisp and don’t yet understand why that’s such an advantage. I introduce the language syntax (what little there is of it), cover interoperability with Java, macros, mutlti-methods, and more. I also cover the functional aspects of Clojure, showing its powerful immutable data structures, working with threads and concurrency, and sequences. Beyond just showing syntax, I also show how to build real applications in Clojure, and give you a chance to do the same. Attending this workshop shows enough to pique your interest and show why many of the people who were interested in Java in 1996 are interested in Clojure now.

Build Your Own Technology Radar Workshop for Architects

5:00 PM MDT

A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.

ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.

Software Architecture Fundamentals, Part 1: From Developer to Architect

9:00 AM MDT

Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, and soft skills. While we can't make you an architect overnight, we can start you on the journey with a map and a good compass.

The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren't there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it's a fast moving discipline, where entire suites of best practices become obsolete overnight.

Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, and soft skills. While we can't make you an architect overnight, we can start you on the journey with a map and a good compass.

• Soft skills
• Continuous Delivery
• Understanding large codebases
• Architecture patterns
• Architecture anti-patterns
• Tooling & documentation
• Integration architecture
• Integration styles
• Introduction to enterprise architecture

Software Architecture Fundamentals, Part 2: Deeper Dive

10:45 AM MDT

Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.

The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren't there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it's a fast moving discipline, where entire suites of best practices become obsolete overnight.

Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.

Agile ATAM
Continuous Delivery for architects
Applying abstraction
Comparing architectures
SOAP vs REST/ WS vs Messaging
SOA deep dive
Integration hubs
Enterprise architecture approaches
Enterprise architecture strategies

Software Architecture Fundamentals, Part 3 (hands-on): Architectural Katas

1:30 PM MDT

To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectureal Katas exercise to apply learnings from the first two parts.

To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectureal Katas exercise to apply learnings from the first two parts.

From the Architectal Katas website:

Architectural Katas are intended as a small-group (3-5 people) exercise, usually as part of a larger group (4-10 groups are ideal), each of whom is doing a different kata. A Moderator keeps track of time, assigns Katas (or allows this website to choose one randomly), and acts as the facilitator for the exercise.

Each group is given a project (in many ways, an RFP–Request For Proposal) that needs development. The project team meets for a while, discovers requirements that aren’t in the orignal proposal by asking questions of the “customer” (the Moderator), discusses technology options that could work, and sketches out a rough vision of what the solution could look like. Then, after they’ve discussed for a while, the project team must present their solution to the other project teams in the room, and answer challenges (in the form of hard-but-fair questions) from the other project teams. Once that challenge phase is done, the room votes on their results, and the next project team takes the floor.

Part 3, Architectal Katas, is an instructor-led hands-on Katas exercise.

Documenting and Presenting Software Architectures

3:15 PM MDT

This session covers two critical soft skills for architects:

• creating clear, concise documentation of software architecture, both structure and decisions
• presenting architectural ideas as clearly as possible

New architects find soft skills like creating lucid documentation and building compelling presentations challenging. This presentation covers a variety of ways to document ideas in software architecture, ranging from diagramming techniques (that aren't UML) to Architecture Decisions Records and ultimately to presentations. The second part of the talk leverages patterns and anti-patterns from the Presentation Patterns book to help architects build clear and concise representations of their ideas.