Draft Development Flow

Overview

• All members of development team are equal partners in the project.

  • Each member contributes to the project through their area(s) of expertise (DB, QA, Design, Development, support, etc.)

  • We all help each other in developing new or fixing existing functionality.

  • Developers share their expertise with the team on best practice for implementing solutions to development tasks including “bugs”.

  • Development work is done on a “best effort” basis.

• Quality is a responsibility that is shared equally by every team member.

  • members with QA/testing expertise are available to provide guidance with respect to best practices for replicating issues, verifying that the solution has addressed the problem and not introduced new ones.

• Core communications should take place within the task.

  • if you require further info from another person, @ them in the discussion. That way, the history is available to all team members if needed.

Development workflow:

Development work is initially done on local environment.

1. Clone the repository

   • Refer to Applications to locate the deployment you need.

2. Replicate the issue. Work with requestor as needed if the request is unclear.

   1. reach out to Olivier Hill if needed

3. Once the solution is developed, test it on the local environment.

4. Create a PR once the solution has passed testing on local environment.

   •       Provide details of what was fixed (would we be able to implement a template similar to one have) for RPAS/SFOC.

5. The PR is independently reviewed/approved. The Developer who provided the fix should be prepared to answer questions.

6. Developer deploys to development environment.

Database changes:

If the solution involves database changes:

• database changes should be done via a script

• scripts should be subject to PR

• GIT has tools for team programming (should be explored more)

Testing the solution before promoting it to acceptance:

1. Solutions should be deployed to the relevant development environment. It should be tested there by another team member, prior to deployment to acceptance.

   1. reach out to another team member to test your solution:

      1. at standup, ask other team members once deployed to development and someone else can pick
                       pick it up to test.

      2. an “@” request to other team members, in the discussion area of the task, will also work.

If a solution fails testing in development

• assign it back to the person who worked on it, with accompanying notes and, if relevant, screenshots.

• The individual who deems the test to be failed should be prepared to provide feedback and a walkthrough of the failure if needed.

Deploying to Acceptance

1. Deploy the fix to acceptance [should be like a dress rehearsal of deploying to prod].

   1. Testing is independently tested by client (PO, someone who is intimately familiar with product

   2. Signoff is based on feedback from the client organization NOT Development.

If a solution fails testing in acceptance

• Assign it back to the person who worked on it, with accompanying notes and, if relevant, screenshots.

• Similar to when something fails in development, the individual who deems the test to be failed should be prepared to provide feedback and a walkthrough of the failure if needed.

Deploying to Production

1. Deployment to Prod (done through formal request)

   1. recommendation to cross-train all members on how to do this.

Implementation of code (and other fixes) directly in prod (by-passing the development process)

• this should be an extremely rare occurrence.

• approval for this should be done through PO and Scrum master.