Difference between revisions of "OSEE/Software Development Process"

Revision as of 18:12, 12 February 2013

Change Request

The OSEE development team utilizes its Action Tracking System (ATS) to capture and track OSEE software actions. These actions reside in a backlog where they are evaluated and prioritized to be resolved, tested and released appropriately using software agile processes.

Users of OSEE have the ability to submit items (e.g. bugzilla) describing something a user wants (e.g. a new feature or a software bug fix). These items are captured in the product backlog in ATS. The OSEE product backlog can consist of features, bugs, technical work, and knowledge acquisition items. Items in this backlog are sorted through a collaborative approach with users/stakeholders and planned for work.

The OSEE development team schedules software iterations that focus on implementing the highest priority actions. As each iteration ends the completed actions are scheduled for an OSEE release for our users where the team receives frequent feedback (Reference OSEE/Testing and OSEE/Deployment).

{Add Diagram}

Software Design

Design considerations:

What open source libraries already provide part or all of the solution? Remove inclusion of unnecessarily specific restrictions (i.e. generalize the solution) Carefully consider consistency with and impact to overall system architecture Minimize the user support this feature will require. Consider use of appropriate software patterns. Consider the concurrency implications – including does the design take advantage of multiple cores Interface design considerations API compatibility - Binary vs. source vs. contract Gracefully handle bad data, invalid states, etc. Usability – work closely with customer on visual interface

Software Implementation Process

The phase in the software lifecyle where the actual software is implemented for the project. This process includes: updating production software, updating test software, verifying changes through unit tests and system level tests, committing changes into version control, making local builds and submitting changes for review.

Test

Tests accompany all new code created. Tests can either be integration tests (end-to-end) functional testing or pure unit tests. For unit tests, JUnit and mockito (http://code.google.com/p/mockito/) are used to quickly create test mock data types. Mockito mock types can be setup to return predetermined values which can be used in assert statements to test functionality. Tests are put into a fragment bundle where the host bundle contains the code being tested. The fragment will have the same name as the host bundle with “.test” appended to it. The package structure will mirror that of the host bundle (i.e. it will not contain “.test” in any package). The test class will have the same name as the unit under test with “Test” appended. Each test method in the test class will be named testMethodName() where methodName() is the method being tested in the unit under test. Each package will contain a package test suite file that lists which classes are run as a part of that test. Within Eclipse, the Emma code coverage tool can be used for unit tests. Unit tests should cover at least 80% of the new code.

Review

Reviews are done using the Gerrit Code Review tool. After code has been written, it is submitted to Gerrit which allows other developers a chance to review the code prior to it being merged into the baseline. Information on how to configure git to use Gerrit can be found here: http://wiki.eclipse.org/Gerrit. Comments can be made in Gerrit in-line of the changes. After the code has been reviewed, use the “Review” button to complete the process. A “-1” should be used if there are comments that need to be addressed prior to the code being merged in. A “+1” should be used if the change looks good. Once two developers have reviewed the code, a committer can then review the change with “+2” to merge the change into the baseline. Note: A review of “-2” from a committer will block the change from being merged in. The IP portion of the review is for preventing unauthorized 3rd party libraries from being packaged with OSEE. If no unapproved external dependencies are included in the change, a “+1” should be given by at least one reviewer. The Verified portion of the review means that the change has been successfully built (i.e. the change does not break the build). If the patch successfully builds, a “+1” should be given or a “-1” if the build fails. (link to review checklist, gerrit workflow)

QA

For QA purposes all tests are run prior to checking in code changes. Gerrit can integrate with Hudson for the “Verified” portion of the review, but that is currently disabled due to the time it takes to run the build and tests. Multiple integration builds are created prior to release and are used by developers to check out new functionality as well as verify prior functionality. Once a build has been used by developers, it is promoted to user acceptance. A subset of users use the new build to verify more functionality. Prior to release, all tests must pass and all changes that went into the new version are verified by doing readiness reviews. These reviews are to double-check that changes we say are in a build are actually in the build that is marked for release.

Deploying A Change

Depending on the type of action, care must be taken to deploy to an production site.

• Additions modifications of Artifact, Attribute and Relation types
  • If changes to the type model are additions or minor modifications, they can be made directly in the production unified type artifact without down-time
  • If the changes include deletions or renames of types, you will need to coordinate converting the database before making the changes to he types.
• Code changes
  • If multiple releases of OSEE are deployed, code changes must be made in a compatible way such that the current release can continue to work while the alpha and beta releases are able to be tested and released to a smaller user audience. One way is to use the OSEE_INFO table to create a flag that allows old code to run until toggled. This allows the development and testing of the new code, but alpha and beta and full releases won't run the new code until the flag is toggled.

Followup changes during and after a release

• If changes are necessary during a release, such as table conversion or converting database attributes, you will need to create a ATS action labeled "During <release id> work". Then add a task in the task tab that explains what work needs to be done and references the Action that it's being done for. Provide enough detail that any OSEE developer can perform the task.
• If changes are necessary after a release, such as cleaning up deactivated or compatibility code, create a ATS action labeled "Post <release id> work". Then add a task in the task tab that explains what work needs to be done and references the Action that it's being done for. Provide enough detail that any OSEE developer can perform the task.

Releases

The OSEE Development process is designed to enable a change to be adequately reviewed and tested such that it could be quickly incorporated into the a next release. The releases attempt to facilitate this.

• OSEE Release
  • Production Release
  • Most Stable Release
• OSEE Release Candidate Beta
  • Next release to be released to Production
  • Used by smaller subset of user base
• OSEE Release Candidate Alpha
  • Nightly snapshot of what has been released into the current RC branch
  • Can be promoted to Beta when changes are ready
• OSEE Development Beta
  • Trusted changes from the development line
  • Normally only used by OSEE developers or users who need to test a single change
  • Unstable and can be updated / restarted anytime
• OSEE Development Alpha
  • Nightly snapshot off development line
  • Only used by OSEE developers
  • Most unstable and can be updated / restarted anytime

Building And Deploying

OSEE Builds and Deployment are done through Hudson. Snapshot builds are kicked off nightly and available the next morning. At anytime, an OSEE developer can select to promote an Alpha to Beta or Beta to Release by activating the promotion through Hudson.

OSEE is currently being deployed automatically to shared location.