Join us in exploring our approach to feature deployments in Drupal that shortens the release cycle and enhances flexibility. Learn how to empower your development team to deliver on-demand features, making "2 weeks" a thing of the past. What We Will Cover: Challenges of traditional 2+ week deployment cycles and their impact on development agility. Introduction to a modern approach for on-demand feature deployments in Drupal. Leveraging feature flags and configuration management to facilitate rapid releases. Practical strategies to ensure code quality, compatibility, and user experience. Real-world success stories showcasing the benefits of shorter release cycles. Key Takeaways: Understand the limitations of traditional feature deployment timelines. Explore the concept of on-demand feature deployments and its advantages. Learn techniques to implement feature flags and streamline configuration management. Acquire insights into maintaining code quality with rapid development. Discover how embracing on-demand feature deployments can enhance development efficiency and user satisfaction in Drupal projects.

1. DRUPAL4GOV.US
2 Weeks is Too Long!
Speeding Up Your Time to Market
Moving Faster, Delivering Better

2. John Doyle
Digital Polygon
CEO, Technical Architect
E-Mail: john@digitalpolygon.com
Interests
● Building a better internet
● Hiking
● Snowboarding
● Sailing the seven seas
● Pumpkin Patches?
https://www.linkedin.com/in/doyle-jd/

3. DRUPAL4GOV.US
Agenda
1. Let’s Talk About Sprints and Releases!
2. Feature Flags
3. Practical Strategies for Implementing
4. Success Stories + Use Cases

4. This is a balancing act

5. Terminology
Feature: A testable set of functionality in a software application.
Sprint: Time-boxed agile iteration for developing a set of features.
Release: Stable version with specific features ready for public distribution.
Deployment: Process of installing and making software available for use.

6. A bit of history

7. Example 2 Week
Sprints +
Release Cycles

8. Why do teams run longer
release cycles?

9. DRUPAL4GOV.US
To gain efficiency
with resources
We organize sets of features into
sprints/releases to try to optimize
efficiencies:
1. QA Testing
2. User Acceptance Testing
3. Regression Testing
4. Load Testing
5. Release Managers

10. DRUPAL4GOV.US
Due to technical
limitations
We also do it to optimize for the
technology/tools on hand:
1. Limited environments (Dev,
QA, Live)
2. Deployment methodologies
3. Dependencies between
features

11. DRUPAL4GOV.US
To reduce risk More time and control over when
features go live:
1. Triple checking our work!
2. Releases are scheduled and
planned across teams
3. Multiple approvals to CYA
4. Rollbacks are scary
5. Security implications
6. “Fuzzy” understanding of
impacts

12. Some common trends we
see

13. DRUPAL4GOV.US
We tend to be inflexible once we define a process
Backlog
Refinement
Itr.
Planning
Daily
Stand-Up
Itr.
Kick-Off
Itr.
Review
Meeting
Itr.
Retrospectiv
e
Pre-Itr 1
Backlog Refinement
Itr 1 Delivery: Development and QA Testing Itr 1 UAT
Itr 2 Delivery
Pre-Itr 2
Backlog Refinement
Itr. 2 Planning &
Prioritization
Itr 2 Kick-Off

14. DRUPAL4GOV.US
We tend to be
inflexible once we
define a process
1. UAT doesn’t happen until after the 2
week sprint is complete.
2. Issues and feedback for one
feature blocks all features.
3. We typically put up walls around
our sprints. Feedback from Sprint 1,
especially changes to scope, get
pushed to Sprint 3 because Sprint 2
has already started.

15. DRUPAL4GOV.US
“Hotfixes” are seen as negative
and only appropriate for critical
issues
Teams are resistant to change - so we
make rigid rules to make us feel secure:
1. Changes to scope need to be placed
into future sprints.
2. It’s not a bug if it wasn’t explicitly in
the Acceptance Criteria.

16. Are we stuck in our
ways?

17. DRUPAL4GOV.US
What’s stopping us?
Fear of the unknown? Comfort of the familiar? Unfamiliar Technology?

18. DRUPAL4GOV.US
Technology
evolves fast.
(and it has!)
1. Containerization makes
infrastructure less expensive
and more scalable
2. More low/no code options for
DevOps and Testing
3. Frameworks reduce
complexity of features

19. Feature Environments Standard with Most
Managed Hosting
1. Pantheon Multidev’s
2. Amazee Lagoon
3. Acquia CD
4. Platform.sh Environments

20. Testing Automation Gets Easier Every Day
Frameworks:
1. Cypress
2. Playwright
No-Code/Low-Code Tools:
1. Ghost Inspector
2. TestGrid
3. LambdaTest

21. DRUPAL4GOV.US
The foundations
are already here
1. Developers embrace these
tools daily.
2. QA/UAT already tests each
feature of a release
independently.

22. DRUPAL4GOV.US
Feature Releases are Easy
1. On-demand feature
environments enable easy
management of releases
2. QA/UAT can break free of
sprint cycles

23. DRUPAL4GOV.US
Releases already
happen outside
our normal sprint
cycle
1. Think about your release
packages as feature
packages instead of sprint
packages.
2. Organize communications
around feature completion
instead of sprint completion

24. DRUPAL4GOV.US
Keys to
Successfully Move
Faster
1. Leverage automation
2. Communicate & set
expectations appropriately
3. Clearly understand impacts of
features

25. Enough Theory…
Let’s Talk Drupal!

26. What are
Feature Flags
A feature flag is a software
development technique that turns a
set of functionality on and off during
runtime, without deploying new code.

27. DRUPAL4GOV.US
Why Use Feature
Flags?
1. Feature flags can be
leveraged to easily decouple
releases from “go-live”.
2. Feature flags can enable
no-code rollbacks.
3. Feature flags can reduce time
to value metrics.
4. Feature flags can reduce risk.

28. DRUPAL4GOV.US
Feature Flags
In Drupal
We usually use:
1. Admin config form
2. Conditional logic around
code/features
3. Helper functions for config
imports or visibility
Image: Gin theme settings

29. DRUPAL4GOV.US
Feature Flags
Contextualized Feature flags can be
contextualized and extend beyond
normal release management. We
will talk about this a little bit more
later, but for now we will stick with
release cycles

30. DRUPAL4GOV.US
Modules &
Themes are
Examples of
Feature Flags
Drupal’s modular nature is built
around feature flags.
Installing or uninstalling a module
or theme in Drupal is an example
of turning on or off a set of
features.

31. DRUPAL4GOV.US
EXAMPLE - Swapping
out an API
Use Case:
Organization is upgrading their
online ordering APIs for all
applications.
1. Implement a new service for
interacting with the new API.
2. Create a new feature flag.
3. Place conditionals to toggle
API calls.
(Depending on use case, an
intermediate service to abstract
out sub-layers is useful!)

32. DRUPAL4GOV.US
EXAMPLE -
Applying New
Branding
1. New theme to control a
majority of display features.
2. Feature flags to support
additional brand functionality.
a. Form swaps
b. Component features
Use Case:
Company rebranding across
existing applications. New brand
release needs to be coordinated
across various parts of the
website.

33. DRUPAL4GOV.US
EXAMPLE -
Separation of
Concerns
Decoupled applications help:
1. Separate forms from website in
form of embeddable widgets
2. Use React/Next/Angular
framework to create forms
3. Forms can be independently
released without risking any
downtime on website
Use Case:
Company uses lot of forms for
lead collection. Marketing team
needs to test forms without
downtime.

34. Success Story
Releasing a new API version
1. 6 month internal project impacting 100’s of
downstream sites
2. 16 hour release window to
coordinate/validate across internal and
external systems
3. 1 Happy website team who checked in,
flipped a switch, confirmed with release
team and went back to bed!
1. New API Services and features were
deployed to production 3 weeks ahead
of time.
2. No disruptions to existing sprints
cycles or releases.
3. No developer interaction involved in
release!

35. Automation Technology Communication
+ +

36. Current
Drupal
Landscape
1. Feature Flags:
https://www.drupal.org/project/f
eatureflags

37. Enterprise
Options
1. Launch Darkly
2. Split
3. CloudBees

38. Thank You!