Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
12. Overview
• No code or demonstrations
• TDD in your current environment
• Continuous Integration
• Continuous Delivery
• Is it worth it?
• Your next steps
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.
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”
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
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
68. Other CI
Considerations
• Repeatable & reliable
• Should be able to run the same build
process locally
• Break up large testing suites
• Remember, “Fail Fast”
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
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
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
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