Loading...

​​Veda Process discussion Synthesis

​​To add to Almanac under Releases > Dashboard

​​

​​

​​The Product Roadmap and the Dashboard Direction provide a very good high-level overview of where we want to take the product.

​​

​​This Almanac section concerns itself with information pertaining to the different releases we do for the dashboard.

​​

​​Types of Releases

​​We’ll essentially have 2 types of releases with associated dates:

​​

• ​​Official releases

• ​​Prod pushes

​​

​​Official releases

​​These releases are tied to project phases (as a result of PI planning), and include communication to a broader audience, with public broadcast when needed.

​​

​​Prod pushes

​​Prod pushes can be seen as smaller intermediate releases within a given project phase. The goal of these prod pushes is to show the work that is being done while at the same time help the team with day-to-day structure. Having smaller goals allows the team to better focus and have a greater sense of accomplishment.

​​

​​These Prod pushes have clear delivery dates that can be related to an important date. For example:

• ​​A particular meeting the stakeholders have;

• ​​Ahead of conference like AGU.

​​

​​If there are no important dates for a long stretch of time we will select a date that becomes our target date. (A good possible date would be before a flex week so the team can rest after a release and the client has a time to gather feedback).

​​

• ​​Why not sprint based releases?

• ​​We want to have some time for QA to check the project, but also give time to the client to check the latest changes. A sprint based release would be too fast paced for it to be efficient.

​​

​​These prod pushes are communicated to selected stakeholders providing a quick update of changes.

​​

​​Development and deployment

​​The Development and deployment process is the same for both release types, with the only change being the degree to which the changes are advertised.

​​

​​Development is done in the veda-ui​ repo.

​​

​​veda-config​ controls deployment to the staging/production environments (main​ - production, develop​ - staging) through github actions. 

​​

​​Releases are first done to the staging environment, reviewed and later deployed to production. Testing and checks should not happen on the production environment, especially once the app was publicly advertised.

​​

​​A technical summary of the process (all done in veda-config​):

1. ​​Once all the features are ready, create a release branch (ex `stage/1.1.0`) from `develop` with a changelog listing all the changes. (See Creating changelogs below)

1. ​​At this point the version​ field in the package.json​ should be updated. See Versioning and tracking releases below.

2. ​​QA steps in and does a global test with real data.

1. ​​These are global tests whose focus should be how the content (existing and new) plays with newly added features.

2. ​​Smaller functional tests are done during the development process as a normal part of it.

3. ​​Address any critical feedback from QA and merge the PR (will cause a staging deploy).

4. ​​Let stakeholders know about the staging update giving a list of changes.

1. ​​At this point, the staging environment may already contain new content added by other people. We can do our best to list content changes as well, but our main focus would be feature development.

2. ​​If there are any specific features we want feedback on from the stakeholder's side, communicate clearly.