page 2Agenda• 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 3Objectives1. Share what our team did to lower risk, improve software quality, andincrease developer productivity.2. Promote discussion around what other groups have done in terms ofbest practices.
page 4Background 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 adoptingsome 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 alarge time sink.All of the above led to spending precious development time manually testing and deployinguntested changes instead of actually developing new features!
page 5The Old ProcessTool or Process Used DrawbacksAnt, various platform-dependent scripts • verbose XML syntax• no standard directory structure• manual dependency managementManual Deploys • undocumented• prone to inconsistencies• duplicated configurationsTask Delegation via e-mail • difficult to track• no prioritization• changes not linked to tasks• manual aggregation of released changesUntested Code Changes • manual visual inspections• changes were prone to bugs• time-intensive• often didn’t know about bugs untilreleased to productionOne shared development DB • shared by entire team for dev.• impossible to have consistent tests• “stepping on each other” was common
page 6Identifying Best PracticesUnit 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 ContinuousIntegration is reduced risk.” – Martin FowlerSandbox Development Databases• Allows developers to work in isolation without impacting others• Provides consistent and stable schema as a basis for tests and experimentation.
page 7The SolutionsSolution What it does AdvantagesBuildr (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 easierSandbox Schemas Provide consistent state of DBschema• Develop and test in isolation• No more stepping on each otherTests (JUnit, Spring) Consistently exercise code • Finds bugs during development• Promotes higher level of confidenceTeamCity (JetBrains) Continuous Integration • Automates testing• Immediate feedback via IDE, emails• Deferred check-ins• Faster developmentAll of the above result in Less Risk, Higher Quality, and Faster Development!
page 8Applying the DRY PrincipalDRY = Don’t Repeat YourselfOld Process New ProcessConfigurations for databaseJDBC properties, etc. wereduplicated for every project.Configurations are defined onlyonce then copied into projectsthat need them at build time.• Our team manages ~20 apps across 7 differentenvironments.• Applying the DRY principal helps to keep themanagement of configurations simple.
page 9Sandbox SchemasAdvantages:1.Faster development time.2.Always have a complete and fullyfunctioning schema to code against.3.No longer impacted by actions ofothers.4.More freedom to try new thingswithout worrying about breakingstuff.5.Easier to test
page 11Check-in Process Using “Remote Run”Advantages of “Remote Run”:1.Never check in code that breaks thebuild.2.Other developers aren’t impacted byyour changes if something breaks.3.The build runs on a remote machine,so you can immediately move on to yournext task.Again, all of these contribute to:1.lower risk2.higher quality3.faster development cycles.
page 12TeamCity (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 14Summary and Next StepsSummaryHigher 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 notificationsNext Steps1. Speed up dev/test/deploy cycle (always room for improvement)2. Integrate a code review tool3. Test coverage reports (what code is not being tested?)4. More tests!
page 15Questions?Open for discussion…Resources Apache Buildr: build system for Java-based applications, including support for Scala, Groovy and agrowing number of JVM languages and tools.http://buildr.apache.org TeamCity (CI server)http://www.jetbrains.com/teamcity “Continuous Integration” article by Martin Fowlerhttp://martinfowler.com/articles/continuousIntegration.html Testing with the Spring Frameworkhttp://static.springsource.org/spring/docs/2.5.x/reference/testing.html