Bring Production server up to date with master branch

[joereddington]

Open Question:

Our policies talk a lot about a production branch - but do NOT specify what happens after that. Our production server is considerably behind the current master branch. There are three ways I see going forward.

• We branch the current master branch into "Production Branch" And leave it only
• We make it a requirement that our server is always running the most recent version of the production branch - and tidy that up now.
• We make the 'unifying' of the codebase with the server an offical release and put together the paperwork for it.

Opinions @greg-westnine?

[joereddington-public]

Had a meeting with greg. We aggreed it was past to:

• Create a new branch called production
• Pull it down onto the server
• Make this an offical release with paperwork.

Plan

• [x] Find out what paperwork we need for a release
• [ ] Write proper release process.
• [ ] Correct documents so that they fit a proper release process.

Notes

• "Releases should be created as Projects. This allows all the change items in a project to be pulled together. They can also be tracked through a processes of development, merging and deployment." (Github Doc)
• "There also needs to be a Release Branch created for each release." (Github doc)
• "Every release must have an associated Release Note. This document, which is a controlled document under the Document Management Policy, must contain: • The release identification • The release date • The contents of the release • Evidence of completion of test procedures For guidance on completing a Release Note see the Development Procedure."

Future Actions

• Review and rewrite the Developement policy/procedure - the policy says 'details in procedure' but they aren't there.
• "Unit tests are written using Jasmine, and run using karma." (Github Doc)
• Deal with the fact that releases might be late.

[joereddington-public]

Let's try writing the process.

'Normal' release process.

1. Create Github Project
2. Add issues to project
3. Choose 'release after' date. Must be at least 14 calendar days away.
4. Add project to roadmap, with 'release after' date.
5. Implement all changes, update labels.

48 hours before a release is made:

1. Product owner must have approved a release note.
   • Release note contains the listing of release contents - contents are locked after approval.
   • Release note contains report of tests run on the release branch.
   • Release note is a marked as a 'controlled document'.
2. Publicly annouce that a release is imenient.

To release

• Merge release branch to production.
• Pull production branch to sever

Okay, that's the policy I want to follow. I think it's simplier than the one we outline and it keeps the important bits. Next action is to rewrite the policies so that this works better. Also to crease a relevent project.

[joereddington-public]

Writing production notes.

After thinking about it, the production notes should reflect what has changed between server versions. So I need to find out what they are.

Release note draft:

Changes

Summary: lots of work on the python back-end...

• Added: The python code now generates correct OBF!
• Added: Many more python tests have been added and are passing.
• Added: Some javascript tests have been added and are passing.
• Refactoring: Lots of refactoring to make life easier.
• Cleanup: We've removed some older files that were getting in the way.
• Fixed: an issue were border colors weren't been identified properly. 27faccc256e9a2a18916692add27ce93252896b7
• Minor: logos and readme files updated.
• bugfix Issue #92

Test report

Next actions:

• Run javascript tests on current master branch and keep track of output.
• Copy release notes into document
• Mark them as approved on road map

[joereddington-public]

Terminal Saved Output Tests for production 1 .txt

Need to work out how to run the old javascript tests.

[greg-westnine]

@joereddington I see the release note comment above. Did you also see the release note template I created, copied here again for convinience?
Release Note Template v0-1.docx

[joereddington-public]

Plan for today

• [x] Check that the instructions in the wiki work on this account (They did, but I fixed them)

• [x] Merge the testing branch into master Done.

• [x] Create the release branch I've created Release-sync-with-server

• [x] Save the test reports

  • Release-sync-with-server-javascript-tests.txt
  • Release-sync-with-server-python-tests.txt

• [x] Rememeber to update the release notes.
  Release-sync-with-server-notes.v.2.0.docx

• [x] Publically Annouuce that a version is going to be released.

  • Blog

[joereddington-public]

Next action is to come back on Friday and do the final release and then pull onto the server. @greg-westnine - can you look over my paperwork for me?

[greg-westnine]

I have reviewed the documentation against the Dev Policy. In the release note is there a discrepancy between the list of changes and the number of issues in the project? In theory there should be an issue for every change, although multiple changes could be combined into one issue. Do we have any evidence of code reviews? Have we conducted functional testing (and if so, where's the test report)?

[joereddington]

Next action - push this to the developemen server and screenshot/cast that it is working. Also at a note in the release note about code reviews.

[joereddington-public]

Suitable evidence of functional testing is the production of speech aid on the staging server: http://www.staging.theopenvoicefactory.org/b1ff7a047f14bd9c571a44d08a7e9c30/?lang=Alex

[joereddington-public]

New (approved) Release-sync-with-server-notes.v.3.0.docx

Due to do new release in 24 hours.

[joereddington]

Ahem - I clearly meant 48

[joereddington]

Up and running! Both staging.theopenvoicefactory.org and designs.theopenvoicefactory.org are running the new production branch, and I've also changed the default branch on the repository.

Smoke testing done - generated this http://designs.theopenvoicefactory.org/10ae77ee3dcda7567201e42827a01010/?lang=Alex, which works fine. Happy with that. Closing now.

EDIT:

• It has a release: https://github.com/eQualityTime/TheOpenVoiceFactory/releases/tag/v1.0
• I've updated the roadmap: https://github.com/eQualityTime/TheOpenVoiceFactory/wiki/Roadmap
• I've updated the controlled documents: https://github.com/eQualityTime/TheOpenVoiceFactory/wiki/Controlled-Documents
• I've marked the issues in the project as done.