Upload
shane-witbeck
View
135
Download
0
Tags:
Embed Size (px)
DESCRIPTION
From 2010, outlines specific steps taken to automate software deploys in order to reduce risk.
Citation preview
Improving Software Quality and Reducing RiskShane Witbeck, Michael Wu RMBS ITMay 27th, 2010
page 2
Agenda
• Objectives
• Background
• The Old Process
• Identifying Best Practices
• The Solutions
• How it works• Applying the DRY Principal• Sandbox Schemas• Typical Development Cycle• Check-ins via “Remote Run”• TeamCity Continuous Integration server• Deployments: Old vs. New
• Summary and Next Steps
• Questions?
page 3
Objectives
1. Share what our team did to lower risk, improve software quality, and increase developer productivity.
2. Promote discussion around what other groups have done in terms of best practices.
page 4
Background
Team and Environment Background: – 6 Developers– ~20 apps: standalone, batch, web apps running Tomcat– 7 Environments including team-managed blades, dWeb– Weekly production release schedule
Releasing high quality, bug-free software in a short amount of time is difficult. The team recognized that the quality of our software could be improved by adopting some best practices.
What can be done about it? First, identify the areas for improvement:
1. Code changes were brittle and difficult to manage.
2. Insecure about the quality of released software due to lack of tests.
3. Testing and Deployments were a very manual process which lead to errors and a large time sink.
All of the above led to spending precious development time manually testing and deploying untested changes instead of actually developing new features!
page 5
The Old Process
Tool or Process Used Drawbacks
Ant, various platform-dependent scripts • verbose XML syntax• no standard directory structure• manual dependency management
Manual Deploys • undocumented• prone to inconsistencies• duplicated configurations
Task Delegation via e-mail • difficult to track• no prioritization• changes not linked to tasks• manual aggregation of released changes
Untested Code Changes • manual visual inspections• changes were prone to bugs• time-intensive• often didn’t know about bugs until released to production
One shared development DB • shared by entire team for dev.• impossible to have consistent tests• “stepping on each other” was common
page 6
Identifying Best Practices
Unit and Integration Testing
• Finds faults early by exercising code early and often.
• Eases maintenance.
• Promotes the idea of “embracing change”, rather than fearing it.
Continuous Integration
• Automates testing
• Provides feedback about changes sooner rather than later.
• “On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk.” – Martin Fowler
Sandbox Development Databases
• Allows developers to work in isolation without impacting others
• Provides consistent and stable schema as a basis for tests and experimentation.
page 7
The Solutions
Solution What it does Advantages
Buildr (Apache) Compiles, Builds, Tests, Archives, Deploys, etc.
• Concise• Promotes “DRY” configurations• Easily extensible using Rake/Ruby• Automated deployments• Leverages Maven repos• Fast!
JIRA (Atlassian) Issue tracking • Eases task delegation• Less confusion about priorities• Links code changes to tasks• Re-assignment is much easier
Sandbox Schemas Provide consistent state of DB schema
• Develop and test in isolation• No more stepping on each other
Tests (JUnit, Spring) Consistently exercise code • Finds bugs during development• Promotes higher level of confidence
TeamCity (JetBrains) Continuous Integration • Automates testing• Immediate feedback via IDE, emails• Deferred check-ins• Faster development
All of the above result in Less Risk, Higher Quality, and Faster Development!
page 8
Applying the DRY Principal
DRY = Don’t Repeat Yourself
Old Process New Process
Configurations for database JDBC properties, etc. were duplicated for every project.
Configurations are defined only once then copied into projects that need them at build time.
• Our team manages ~20 apps across 7 different environments.
• Applying the DRY principal helps to keep the management of configurations simple.
page 9
Sandbox Schemas
Advantages:
1.Faster development time.2.Always have a complete and fully functioning schema to code against.3.No longer impacted by actions of others.4.More freedom to try new things without worrying about breaking stuff.5.Easier to test
page 10
Typical Development Cycle
page 11
Check-in Process Using “Remote Run”
Advantages of “Remote Run”:
1.Never check in code that breaks the build.2.Other developers aren’t impacted by your changes if something breaks.3.The build runs on a remote machine, so you can immediately move on to your next task.
Again, all of these contribute to:1.lower risk 2.higher quality3.faster development cycles.
page 12
TeamCity (CI Server)
TeamCity provides detailed information:• IDE integration to easily view test results and manage your changes.• JIRA integration to easily view the context for your changes.
page 13
Deployments: Old vs. New
page 14
Summary and Next Steps
Summary
Higher quality, Lower Risk, Faster Development Time– 0 to hundreds of tests
– Automated deployments and server tasks via Buildr
– Sandbox schemas
– Easier task management via JIRA with notifications
– Continuous Integration and automatic notifications
Next Steps
1. Speed up dev/test/deploy cycle (always room for improvement)
2. Integrate a code review tool
3. Test coverage reports (what code is not being tested?)
4. More tests!
page 15
Questions?
Open for discussion…
Resources Apache Buildr: build system for Java-based applications, including support for Scala, Groovy and a
growing number of JVM languages and tools. http://buildr.apache.org
TeamCity (CI server)http://www.jetbrains.com/teamcity
“Continuous Integration” article by Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
Testing with the Spring Frameworkhttp://static.springsource.org/spring/docs/2.5.x/reference/testing.html