Improving Software Quality and Reducing Risk

Improving Software Quality and Reducing RiskShane Witbeck, Michael Wu RMBS ITMay 27th, 2010

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?

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.

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!

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

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.

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!

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.

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

Typical Development Cycle

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.

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.

Deployments: Old vs. New

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!

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

Improving Software Quality and Reducing Risk

Technology

Transcript of Improving Software Quality and Reducing Risk