Development and release process

• Perfect slice

• Stakeholders

• Design process

• Development process

• Performance testing

• Release process

Perfect slice• Develop feature from top to bottom

• Design, testing, development, review, performance testing, model loader additions, internationalisation reach-out, QA, release, roll out into production, further testing

• Make it ready to be used in large-scale production environment

• Prioritising slices becomes very important

Stakeholders

• OAE has multiple institutions as stakeholders

• All have unique (edge case) requirements

• Need to deal with this as an OS project

• Need to keep the UI simple

• Shared edge cases can be layered away

Design

• Starts with a need

• Create wireframes

• Go through user testing

• Deliver finished designs to development

Development• HTML, CSS and JavaScript implementation in front-end

• Back-end REST APIs

• Write tests to verify the implementation

• Front-end: CasperJS (headless webkit)

• Back-end: Mocha (through REST APIs)

• Code review

• Merge into master (more on this later)

Performance testing

• Tsung

• Simulate users in order to test scalability (stress testing)

• Decrease in performance === investigate/hold off release

• Before every release (major or maintenance)

• Analysis of Tsung graphs and Circonus data

Release• A major OAE release is usually defined by the

implementation of a new user facing piece of functionality (e.g. `Following` feature)

• An OAE maintenance release is usually defined by a set of refinements to already existing functionality (e.g. Design refinements to `Following` feature or non-user facing functionality)

• All releases (major or maintenance) go through the same workflow

Release

• Decide to release

• Bug bash (on optimised build)

• Triage bugs, fix blockers first

• Reiterate

• Start final release process

Release front-end• Update version in package.json

• Fix versions for used node modules

• Note: In development we use the latest modules to detect any problems when those change to a newer version

• Clean out node_modules and test with fresh install one final time

• Tag new version in Github (e.g. 1.0, 2.3)

• Tagging ‘copies’ and ‘freezes’ the code at the point the tag was created.

• `grunt release` and publish to a VM and test

Release back-end• Update version in package.json

• Fix versions for used node modules

• Note: In development we use the latest modules to detect any problems when those change to a newer version

• Clean out node_modules and test with fresh install one final time

• Tag new version in Github (e.g. 1.0, 2.3)

• Tagging ‘copies’ and ‘freezes’ the code at the point the tag was created.

• Publish PPA

• `grunt release` and publish to a VM and test

Sources• https://www.slideshare.net/bertpareyn/oae-

development-and-release-process/

• http://oaeproject.org/blog

• http://crowdin.net/project/apereo-oae

• https://github.com/oaeproject/3akai-ux

• https://github.com/oaeproject/Hilary

• https://oae.oae-qa0.oaeproject.org/