The document outlines the development and release process for an open source project called OAE. It describes steps like designing features, developing code, testing performance, and releasing updates. Key aspects include developing features from start to finish, dealing with requirements from multiple stakeholders, and thoroughly testing releases through methods such as Tsung load testing before deploying updates to production environments.

1. Development and
release process

2. •
Perfect slice
•
Stakeholders
•
Design process
•
Development process
•
Performance testing
•
Release process

3. 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

4. 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

5. Design
•
Starts with a need
•
Create wireframes
•
Go through user testing
•
Deliver finished designs to development

6. 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)

7. 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

10. 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

11. Release
•
Decide to release
•
•
Triage bugs, fix blockers first
•
•
Bug bash (on optimised build)
Reiterate
Start final release process

12. 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

13. 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

15. Sources
•
https://www.slideshare.net/bertpareyn/oaedevelopment-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/