Steady as She Goes. How the VIVO developers work to deliver a stable platform

Transcription

1 Steady as She Goes How the VIVO developers work to deliver a stable platform

2 Overview These practices: are by and for the Cornell development team. are applied to the main VIVO code base. The next challenge: practices that welcome the community 2

3 The growth of VIVO code Release Date Megabytes Files Changes* 0.9 Jan 29, Apr 14, Jul 29, Oct 11, Feb 16, Jun 2, Jul 28, *Not completely accurate 3

4 The challenge Keep growing and changing without alienating our users. Encourage our users to update to the latest release. Minimize their fear provide a reliable product. Minimize their effort provide an upgrade process. 4

5 Philosophy 101 Defined processes are good. Automated processes are better. Building process requires resources. We control the process. The process doesn t control us. 5

6 Philosophy 102 Put the framework in place, and others can populate it as time allows. 6

7 Day to day process DEVELOPMENT 7

8 Issue tracking Feature requests, improvements and bugs are entered into JIRA. Used in: planning the features of each release. communicating among the team. structuring the release docs. 8

9 Issue tracking Input from the community: entered into a form on vivoweb.org we respond to the submitter, whether we act on the issue or not. 9

10 Version control Subversion at SourceForge provides: read access to anyone read-write access to developers create branches for development 10

11 Unit tests 637 tests on 60 classes Code coverage? Vitro and Vivo comprise 962 classes Run on demand while developing in Eclipse on every build unless overridden on Continuous Integration server (Hudson) 11

12 Build script Written in Apache Ant Builds Vitro and Vivo from scratch Runs unit tests Deploys to Tomcat Every change by a developer goes through the same steps as the final installation. 12

13 Continuous Integration Uses Hudson Poll Subversion for changes. Check out a clean copy. Perform 3 tasks: Do a clean build Pre-compile JSPs Check licensing info Send notifications if a task fails. 13

14 What will the transition be like? PREPARE FOR RELEASE 14

15 Performance testing JMeter Too light to be called load testing. Single-threaded Home page, Index page, Search results Individual profile page, AJAX calls Logged in or logged out 15

16 Performance testing Compare to the previous release. Should we be alarmed? Test small, medium, and large models. Production data from different sites. 16

17 Data migration code When the structure of the ontology changes, write a migration routine. A seamless transition for installed sites. Log files show the details. Tools are tested against production data from installed sites. 17

18 Upgrade documents Overview of what has changed New deployment methods and properties Changes to the architecture Description of data migrations Changes to the theme 18

19 Delivering the product RELEASE 19

20 Explicit process A written series of steps Meetings notifications code freeze release candidates announcements 20

21 Issue tracking Clear all blocking issues Any bug is entered as a blocker. May be downgraded by team leads. Assign time estimates to all blockers. Maybe move issues to the next release. 21

22 Daily meetings Scrum-style standup meetings Start 2 weeks before the release Are the dates realistic? What is the critical path? Who needs help? 22

23 Branches and Tags Create a branch for the release so developers can continue on the trunk. Branches are never merged back in. Branches extend through point releases 23

24 The release branch 24

25 Automated acceptance tests Selenium 14 test suites 180 tests over 12,000 steps 25

26 Manual acceptance tests Process is too new for automated tests Process does not permit automated testing is involved requires special configuration Test requires eyes on the screen 26

27 Release candidates Each time we think we have all of the bugs, we put a candidate out for testing. 27

28 INTO THE FUTURE 28

29 An iterative process Each release, we find something to change. We continue to automate. What s our next improvement? 29

30 Going public Open issue tracking something on SourceForge or equivalent Release process announce each step so distributed developers are prepared What replaces the stand-up meeting? How do we test release candidates? 30

31 Questions? Comments? 31