So You Want To Go Faster?
How frequently does a good agile team deploy to production? Not every team is capable of deploying "on every commit". What does it take for a team to even start deploying at the end of each sprint, or each week, or each day?
Most companies don't realize that deploying more frequently often requires both significant technical change as well as cultural change. In this talk, I'll guide you through what it takes to deploy more frequently, both from the technical side of setting up pipelines as well as the organizational side of removing red tape. I'll draw on the unique challenges that teams must overcome at each step of the way, from deploying once a month all the way down to full continuous delivery. If your team has been struggling to go faster, come see how you can change to get there. And if you already are at full continuous delivery, come see how to go even faster than that!
Outline/structure of the Session
- Introduction / About Me (1 min)
- Meet the team (fictitious team) (4 min)
- Current State: Deploys once per month (basically waterfall)
- Deployments are manual, error-prone, dreaded
- Weekend Downtime
- Environments are all special snowflakes
- Some automation in Jenkins for Continuous Integration
- Sends out release notes email
- Deploying After Each Sprint (8 min)
- Team needs to get a handle on environment inconsistency (configuration management)
- Team should start thinking about automated deployments to environments
- Team needs to think more about getting code "ready to ship" by the end of the sprint
- Team really needs to start caring about pipeline status
- More frequent deployments doesn't equate to more risk
- Deploying Once Per Week (8 min)
- Team needs to automate their deployments
- Need to have a zero-downtime deployment, can't keep deploying every weekend (people will quit!!!)
- Team should start thinking about feature toggles
- Try to eliminate any remaining reasons to SSH into a server
- With more frequent deploys other teams (Security, Systems Engineering, etc) are going to start complaining
- How does the team manage what version to deploy? Tags, Unique ID, named release?
- Do Executives / Higher-ups really need to give us "approval" in order to deploy?
- Why do we need a "QA" team? Can they keep up with us?
- Deploying Every 2-3 days (8 min)
- High confidence in the deployment pipeline
- Unfinished/Unready code must be behind a toggle!
- Logs are distributed. Developers never SSH into a server for any reason!
- Smoke tests for environments
- Automated Acceptance Tests to test features
- Separated pipeline for infrastructure hardening
- Monitoring / Alerts for system performance
- Who on the team should be allowed to deploy? Should the process be simple enough that non-developers can?
- If our team is using some kind of tagging system for deployments we'll need to find a way to automate it
- Bugs are being resolved a lot more quickly now
- Roll forward vs. Roll back
- Deploying Every Day / Every Commit (8 min)
- Team cannot let the pipeline get blocked!
- Smoke tests that run after each deployment
- Monitoring / Alerts setup and being used (we need to know if the system goes down!)
- Automated notifications to interested parties on deploy
- Change of mindset: Deployments no longer signify functionality being released, toggles do!
- A small number of bugs in production is ok! Fixing them is easier than preventing them
- The team doesn't "test to make sure everything is still ok in prod"...ever!
- Can you go faster than "on every commit"? (5 min)
- Upper limit on how fast your pipeline can deploy
- To go faster, consider event driven architecture
- Multiple teams work on the same feature, plug-in solutions that respond to the same events
- Example: algorithms that generate sales/deals for customers
- Summary (3 min)
- Attendees should leave the talk with a full understanding of the different challenges for deploying at these intervals:
- Once per sprint
- Every few days
- On Every Commit
- Attendees should be familiarized with common technical solutions to these problems, including:
- Automation through delivery pipelines in Jenkins (or some other CI tool)
- Feature toggles and their role in code
- The role of automated acceptance testing and smoke testing (especially when you go fast)
- Using configuration management tools to create consistency across environments
- Strategies for versioning and dealing with "in transition" states
- Attendees should be able to answer to these common cultural questions:
- Does more frequent doesn't equate to more risk?
- How do you ensure quality without a dedicated QA team of manual testers?
- Who should be responsible for authorizing deployments to production?
- Do all deployments deliver functionality?
- Are bug counts the only way to measure quality?
Developers or DevOps engineers who are tired of long deployments and want to know how to achieve Continuous Delivery
Some general familiarity with software development. The talk will keep things high level though we will be discussing a lot of DevOps concepts that are technical in nature.
schedule Submitted 1 week ago
People who liked this proposal, also liked:
How Agile Technical Practices Facilitate Disruptive InnovationRob Myers
schedule 1 week agoSold Out!
Leaders of development teams want to be able to adapt their existing product to innovative ideas and shifting market conditions. This is often the reason organizations "go Agile," yet this flexible ability to deliver rich business value is often frustratingly out of reach.
Agile teams and their management are also familiar with the value of individual development practices. For example, Test-Driven Development's ability to catch defects early, and to provide the team with the ability to confidently extend the product. What Rob has found by working with a number of teams, each for six months or more, is another much greater--and more rare--source of business value resulting from diligent attention to software craftsmanship and the resulting two-way trust that forms between Development and Product.
You will hear a handful of surprising (but real) first-person tales, each detailing a time when changing market forces, dramatic pivots, disruptive technological changes, or insightful requests were managed by the delivery team within a single two-week sprint. Each of these "Black Swan User Stories" (Rob's term for powerful, risky, and unforeseen user-stories) resulted in multiplying user productivity, opening whole new markets, or delighting and retaining critical customers.
What we found in each case was that rapid completion of our Black Swan User Stories was the result of diligent, disciplined application of a few Agile technical practices; and that this resulted in the concrete realization of organizations' long-held expectations for Agile software development.
Understanding Agile & Lean CoachingPaul Boos
schedule 4 days agoSold Out!
So you are considering getting a coach to help you in your transition to Agile. Or perhaps you are an Agile practitioner considering becoming an Agile coach. What do these Agile coaches do? What makes them different?
This session will enter the foyer of the house that describes what coaches do and considerations one can have when they think about coaching (including hiring one). Prepare to be challenged and to learn a bit of what it takes to be or work with a coach; it has little to do with courses or certifications, though they may help. In covering what coaches do, one can now begin to think along the lines of what the skills one may need to improve.
Catalytic LeadershipPaul Boos
schedule 1 week agoSold Out!
Losing good people during your transformation? Getting more resistance than you expected? You may be producing unwanted reactions in the way you are leading your people through change. If you want your Agile transformation firing on all cylinders without the harmful side-effects, people at all levels need to become Catalysts.
Catalytic leaders help lead continual improvement - change. How can we do that? How can anyone be a leader? This workshop will mix presentation with exercises to help you understand practical things you can do to lead change effectively.
Kanban in Action: Thoughtfully Observing Flow
Imagine you were hired to provide consulting assistance for a new team just starting out with Kanban. The team has been struggling with their implementation and is looking forward to your expert guidance, support, and advice. It’s your first day and you just walked into the team room to look at their board. You want to make smart observations and thoughtful interpretations so you can have meaningful conversations with the team members. The team starts assembling in the team room for the daily standup and you plan on making some comments afterwards.
What comments would you make? What thoughtful questions would you ask?
This interactive presentation provides a detailed look at how to interpret and thoughtfully observe Kanban Boards to better understand the work of your teams. We will start with an overview of the Lean Kanban Method and then proceed through a series of interactive exercises that give you an opportunity to review and interpret various Kanban boards. The exercises will increase your understanding of Kanban systems and provide opportunities to practice interpreting various board setups so you can have thoughtful and meaningful conversations with your teams.
Improving Your CyberSecurity Posture with Agility
As we have seen from recent reports in the news and elsewhere, cyberattacks come many sources. How can we use Agile practices to improve organization's information security posture?
In this session, Dan and Paul will discuss techniques that can help make information security an important part of software development and speed your response to threats. The use of hardening pipelines, dark stories, and user stories/acceptance criteria that map to policy guidance based on NIST 800-53 controls will be discussed and how each approaches improving your security posture from a different angle.
Powerful Tools for Affecting Change: Personal and Social IdentityJulie Bright
schedule 1 month agoSold Out!
Scrum Masters and Agile Coaches wear many hats, but one of the most important is that of the Change Artist. Understanding what people need in order to move through a change curve is critical to success, but often overlooked in the toolkit is the role of Identity. Our self-perception, both as individuals and within the context of a group, is foundational to our psychology, and can be leveraged to affect and nurture powerful, long-lasting change.
Everything Object Oriented Design Taught Me About LeadershipDaniel Davis
schedule 1 week agoSold Out!
Most senior software developers eventually find themselves in a position of leadership. About two years ago, I was in the same boat, being asked to take over as tech lead for a large agile project. I felt unprepared, I didn't know the first thing about being in charge! I found myself falling back to the thing I had spent years learning: object-oriented design principles.
In this talk, I'll walk through some of the parallels between clean coding and leadership. I'll discuss some design anti-patterns with different styles of leadership and how to avoid falling into classic management traps. If you've always felt like your bosses treat you like a class with too many responsibilities, come learn how to code better leadership!
Jira 101JENNIFER M FORREST
schedule 4 days agoSold Out!
This session is for newbies to JIRA who want to learn how to survive (and thrive!) using JIRA every day. We'll be walking through a variety of real projects in JIRA and you'll come away with a better basic understanding of the tool.