SoftwareWorkflow

This page documents the proposed formalization of the current PHGrid workflow. It's in Draft right now and is open for any comments. It's intended audience is that of technical participants in the PHGrid project.

The reason we use agile methods are to:

    • reduce regression type bugs by performing frequent builds and deployments to confirm that what works in one developer's environment will work in others (and more importantly the training, integration test and production environments)
    • accelarate the sharing of ideas (code) among developers by letting others see what's going on
    • increase feedback from users and stakeholders by showing changes as soon as possible
    • Prioritize changes efficiently by reducing the round-trip between stakeholder idea and software realization ("Is this what you're thinking of?")
    • Match development and release cycles of partner projects (Globus, cagrid, RODS, apache)

The flow of code should progress from developers workstations to through PHGrid's environments to production in an orderly manner:

I think there will be a few specific timeframes we'll work with:

    1. Daily/ nightly check-ins: let collaborators know what has changed, serve as a backup, reduce integration time for any shared components. These check-ins should be covered by JUnit tests that all pass.
    2. As needed development intregration builds: tests code from multiple developers in an environment that mirrors production/training/VA
    3. Weekly deployments to training: provides a public environment for user experience testing and demonstration.
    4. 2/3 months production deployments for moving code from training to production. This includes deployments to the VA environment for scanning and configuration testing. This date is arbitrary, but having a set schedule makes it possible to move more code to production (since planning CRs for productions takes up a decent sized chunk of time).

Roles (I feel silly documenting these roles, but thought that I will to increase clarity) (a single person can have multiple roles):

    • Stakeholder (anyone interested in the success of the project)
    • Business Steward (owner of the project)
    • Security Steward (security reviewer of project)
    • User (accesses the running code of the project)
    • Programmer (adds or modifies to the project)
    • Administrator (maintains the running code of the project)
    • Project Manager (assigns work, tracks project)
    • Tester (tests code)
    • Hosting (team of individuals who maintain the hosting environment)
    • Security Analyst (team member who assists with security tasks)

These steps should be the simplest possible approach to developing software in an agile manner that still has transparency and accountability.

Steps:

    1. Stakeholder enters a change into the tracker (either a feature request or a bug). The change is described as best as possible by the submitter.
    2. Business Steward prioritizes the change based on the current and projected work load.
    3. PM updates the change with details (version target, further description, etc.) and assigns it to a programmer.
    4. Programmer estimates a initial amount of work and a completion date (rough estimate obviously)
    5. Programmer creates a rough test plan and use case description (if it doesn't exist from step #1) and begins development.
    6. Programmer checks in changes as possible (preferably nightly) providing they pass the JUnit tests that the programmer creates.
    7. Programmer deploys latest changes to training every Friday. Deployment involves:
      1. Creating a label in SVN (e.g. 20090922)
      2. Building based on a checkout from the above SVN label
      3. Updating training node / app server with components
      4. Training node scanned by Security Analyst
      5. Performing test plan of all deployed components to confirm deployment
    8. As a change is completed, the programmer changes the tracker item status to pending
    9. Project manager assigns a tester (a programmer other than the original programmer assigned to change)
    10. Tester tests change. Testing involves:
      1. Tester runs through the test plan, if necessary, updating the test plan with details.
      2. Programmer makes appropriate fixes
      3. Tester confirms code change by adding a comment to the tracker item with the build label that contains the completed change (e.g. "GV1.0.1.20090922")
    11. Every 2-3 months a specific deployment is selected to be migrated to production. Production involves
      1. Project Manager submits a CR to the security steward
      2. Programmer performs a build based on a checkout from SVN of the above label
      3. Programmer updates the VA server with components
      4. Programmer performs a test plan of all deployed components to confirm deployment
      5. Hosting performs a scan VA environment for security vulnerabilities
      6. Repeat 2-5 if vulnerabilities require changes.
    12. Every 6 months or so the version is incremented (e.g. from "GV1.0.1.20090922" to "GV2.0.0.20100322")

The idea here is that every change to the software can be described within a tracker item that contains a history of the work performed, when it is planned for release, when it is tested and when it is moved to production. So any production rollout can be described by the changes contained within the tracker items.