The document discusses advanced practices for software development beyond Test-Driven Development (TDD), emphasizing continuous integration and delivery to enhance the software release process. It highlights the importance of rapid feedback, collaboration among all team members, and strategies like Minimum Viable Product and feature toggles to manage incomplete features. The overall goal is to eliminate barriers to release, facilitate regular deployments, and improve the team's efficiency and confidence in delivering software.

1. Beyond TDD
Enabling Your Team to Continuously Deliver Software

2. Me
• Fightin’ Texas Aggie
• .Net and PHP Developer
• UNIX and Windows Sysadmin
• Senior Consultant at
Improving Enterprises
• chris@chrisweldon.net

3. Promotion

4. Promotion
• @neraath

5. Promotion
• @neraath
• #adn12

6. Promotion
• @neraath
• #adn12
• #tdd

7. Promotion
• @neraath
• #adn12
• #tdd
• #thisguyisawesome

8. Promotion
• @neraath
• #adn12
• #tdd
• #thisguyisawesome
• #bestspeakerever

9. Promotion
• @neraath
• #adn12
• #tdd
• #thisguyisawesome
• #bestspeakerever
• #terrbilepresenter

10. Promotion
• @neraath
• #adn12
• #tdd
• #thisguyisawesome
• #bestspeakerever
• #terrbilepresenter
• #worstpresentation

11. is hiring!

12. Overview
• No code or demonstrations
• TDD in your current environment
• Continuous Integration
• Continuous Delivery
• Is it worth it?
• Your next steps

13. Agile

14. in g
B e Agile

15. “Working software is
the primary measure of
progress”

16. Tests

17. Unit

18. Load

19. UI?

20. Performance

21. Unit

22. Unit
Testing

23. Unit
Testing

24. Unit leads to
Testing

25. Unit leads to
TDD
Testing

26. Unit leads to
TDD
Testing

27. Challenges Getting Past
TDD

28. Who/What Broke My
Build?

29. Integration

30. Integration
You Don’t See the Forest thru the Trees

31. Code Quality

32. Coding Standards

33. using System;
namespace BeyondTDD
{
public class StringUtils
{
/// <summary>
/// Strips double quotes from the provided <paramref name="sourceString" />.
/// </summary>
/// <param name="sourceString">The source to strip quotes from.</param>
/// <returns>A string without quotes.</returns>
public string StripQuotes(string sourceString)
{
if (string.IsNullOrEmpty(sourceString))
throw new ArgumentNullException("sourceString");
return sourceString.Replace('"', string.Empty);
}
}
}

34. using System;
namespace BeyondTDD
{
public class StringUtils
{
/// <summary>
/// Strips double quotes from the provided <paramref name="sourceString" />.
/// </summary>
public string StripQuotes(string sourceString) {
if (sourceString == null) {
throw new ArgumentNullException("sourceString");
}
return sourceString.Replace('"', "");
}
// Look at all the spaces, ma!
}
}

35. using System;
namespace BeyondTDD {
public class StringUtils
{
/*** I had to change this method cause I'm a n00b.
public string StripQuotes(string sourceString)
{
foreach(char c in sourceString) {
if (c == '"')
{ sourceString[c] == ""; }
}
return sourceString;
}
*/
// comments? what comments? this makes sense, right?
public string StripQuotes(string sourceString)
{
if (sourceString == null)
{
//throw new ArgumentNullException("sourceString");
// I <3 Exception more than anything else.
throw new Exception("sourceString");
}
return sourceString.Replace('"', "");
} } }

36. I will hunt you down and shoot you like a duck dog.

38. Security
srsly?
what hacker
wears a tie?

39. Creating and Deploying
a Releasable Package

40. The Feedback Loop is
Wide Open

41. How to Improve?

42. Continuous Integration

43. CI is a Practice

44. CI is a Practice
• Integrate now, and frequently, rather than
at the end of development
• Smaller surface area for integration
problems
• Devs can rapidly fix when they occur
• Reduces “Integration Hell”

46. Martin Fowler

47. Practical CI
involves Tools

48. What do you need?
Build Server Accessible by
Source Control
Entire Team
Your Shell Scripts
Commit to
trunk / master / mainline
often

49. What do you need?
• Automate your build
• Manual steps increases risk of failure
• Make your build self-testing
• Writing unit tests is not enough
• Must be able to execute tests with a
single command

50. What does it do?

51. What does it do?
Runs Tests

52. What does it do?
Runs Tests

53. What does it do?
Generates
Runs Tests
Documentation

54. What does it do?
Generates
Runs Tests
Documentation

55. What does it do?
Generates
Runs Tests Quality Analysis
Documentation

56. What does it do?
Generates
Runs Tests Quality Analysis
Documentation

57. What does it do?

58. What does it do?

59. What does it do?
Integrates
projects

60. What does it do?
Integrates
projects
Project Status
is Visible
to the
Team

61. What does it do?
Integrates
projects
Project Status
is Visible
to the
Team

62. “Fail Fast”

63. “Fail Fast”
This Closes our Feedback Loop

64. “Fail Fast”
• Every commit (to the trunk) should be
built
• Keep the build fast
• Notify (and make visible to) the entire
team
• Intrusively notify the team of failures
• Make sure to fix the build after it’s broken

66. Word to the Wise: Don’t Break the Build!

68. Other CI
Considerations
• Repeatable & reliable
• Should be able to run the same build
process locally
• Break up large testing suites
• Remember, “Fail Fast”

69. If it’s difficult or painful,
do it more often.

70. Continuous Delivery

71. Continuous Delivery is
developing in such a way that
software is always ready for
release.

72. More on Being Agile

73. More on Being Agile

74. More on Being Agile
“Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.”

75. More on Being Agile
“Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.”

76. Users Drive Your Value
Much like beauty, value is
in the eyes of the beholder.

77. Get In Front of Users
Sooner

78. The “Last Mile” Problem
“The further apart your releases are, the more risk you
introduce that the changes are wrong.”
- Jez Humble

79. Strategies

82. Minimum Viable Product

83. Do the minimum
amount of work
necessary

85. Get in front of users
immediately

87. Usage Patterns

88. Measure Conversion /
Behavior Expectations

92. Why?
• We want constant feedback
• How else do we know what we’re doing
is valuable?
• Constant testing and improving our
delivery process

93. What about Large
Features?

94. Incomplete Features

95. Incomplete Features
• Sometimes a feature is just too big

96. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases

97. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!

98. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!
• Beware the Beta

99. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!
• Beware the Beta
• Solution: Feature Toggles

100. Feature Toggles

101. Feature Toggles

102. Feature Toggles

103. Feature Toggles

104. Feature Toggles

105. Clear the Delivery Path
• MVP helps to make the team think about going to
production as soon as possible
• Deal with Production Gates
• Work to cut, simplify, or work around
organizational red tape
• Find “creative solutions” that satisfy everyone
while emphasizing the business goals

106. Everybody has
responsibility for the
release process

107. DBAs UX QA
Everybody has
responsibility for the
release process
Operations Developers Managers

108. Everyone’s
Responsibilities
• How do I automate the testing and
validation after deploying?
• How do I make it easier for the team to
release?

109. Developer
Responsibilities
• How do I keep my software releasable?
• What does it take to deploy my software?

110. DBA Responsibilities
• How do I automate schema deployments?
• How do I give the build server autonomy
to deploy?

111. Ops Responsibilities
• How do I want the software to be
deployed?
• How do I give the build server autonomy
to deploy?

112. Tester Responsibilities
• Did the automated deployment succeed?
• This is not the same as testing software.

113. Deploy

114. Deploy
• Use the same mechanism for every
environment
• Should be simple
• For products, use the same mechanisms as
your customers

115. Deployment for SaaS
• FTP/SCP
• PowerShell
• Shell Scripting
• MSBuild
• MSI/Installer Packages

116. Deployment for
Products
• Windows Installers
• Built-in, InstallShield, Wise,VISE, etc.
• Installer (Mac OS)

117. Deployment Quality
• Important to establish trust
• End-to-end functional tests become more
valuable
• Behavior-Driven Development helps to
realize this
• Other quality metrics become just as useful
• Performance, compatibility, security

118. Deploy
• When you’ve deployed, have automated
smoke tests validate a successful
deployment
• If something’s wrong:
• Turn off the feature or rollback
• Don’t “hack” a fix

119. If it’s difficult or painful,
do it more often.

120. Is it worth it?
• By removing barriers, rehearsing, and
continuously improving the release
process, the risk of a release is reduced
• Becomes a regular occurrence rather
than a traumatic procedure
• Everyone is involved in making the release
process more automated & efficient

121. Is it worth it?
• Feedback determines the viability of your
feature
• Increases confidence when it’s right
• Decreases cost when it’s wrong

122. Moving Forward
• Identify a single task
• Something that is particularly time
consuming and/or painful
• Automate the task
• Start collecting metrics
• Build team confidence

123. Moving Forward
• You need to talk to the business
• Ask these questions:
• Would you like to set the release schedule?
• Would you like to minimize risk during deployments?
• Would you like to maximize investment on features
our customers really want?
• Be sure to alert them of the up-front investment
required!

124. Moving Forward
• Need help?
• After the talk, or after hours party
• askanagilist@improvingenterprises.com

125. Questions?

126. Thanks!
spkr8.com/neraath

127. References
• http://www.informit.com/articles/article.aspx?p=1829417
• http://www.informit.com/articles/article.aspx?p=1750200
• http://kief.com/the-conflict-between-continuous-delivery-and-traditional-agile.html
• http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/