[SPEC] dApp Release Process and Proposed Improvements

[AtelyPham]

Current Release Process on the webb-dapp Repo

1. Create a release branch from the develop branch.
2. Manually update the version in package.json and CHANGELOG.md.
3. Open a pull request with a [RELEASE] tag on the title, choosing the base branch as develop.
4. Run a force merge on the master to develop after merging the release pull request on develop to trigger the release of dApps on Npm and Github.

Current Pain Points of the Release Process

• Manually updating the version in package.json and CHANGELOG.md takes time and is cumbersome for multiple app releases.
• The release process still requires an admin to run a force merge on the master.

Improvement proposals

• Utilize tools to automate the updating and detection of versions and changes.
  • Release-it
  • changesets
  • Nx plugin for versioning and CHANGELOG generation
• Implement a GA to automate the force merge on the master to develop process.

@drewstone, @devpavan04, and @vutuanlinh2k2, please review this issue and provide your feedback. Thank you.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[AtelyPham]

There is one drawback of our current release process is that merging develop into master triggers the deployment of all apps by the CI systems, potentially leading to unwanted releases.

For instance, if you want to release a fix for stats-dapp only, and you merge develop into master, the develop branch will contain code changes for all apps. Fleek, constantly monitoring the master branch, will execute the deployment. Consequently, this will roll out all app changes, which might include undesired deployments.

[drewstone]

Is there any way we can monitor changes for a specific app and execute releases for the apps only?

[AtelyPham]

I'm not entirely sure if Fleek supports this feature, but I can certainly use your question as a starting point for my investigation.

[drewstone]

Closing since I think we've found process now.

[AtelyPham]

The purpose of this issue is to automate the process. The current process still has some pain points:

• Manually updating the version in package.json and CHANGELOG.md is time-consuming and cumbersome, particularly for multiple app releases.
• The release process still necessitates an admin to execute a force merge on the master.

I believe we can automate these tasks.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[yuri-xyz]

Thoughts:

• Using the release-it tool that you mentioned seems like a great idea, it seems more appropriate than having a Slack command.
• Since now we're using commitlint, that makes autogenerating changelogs much easier!
• We should get rid of the old GitHub workflows for releases
• Adopting a release schedule could be a great idea, something along these lines perhaps:
  • Early in the Week (Monday/Tuesday): Major updates. Gives us time to throughly fix any issues that arise from many changes.
  • Midweek (Wednesday/Thursday): Minor updates. Avoids Monday rush and Friday wind-down.
  • Avoid Fridays and Weekends: Critical issues could be left live over the weekend!

Idea going forward:

• We can fetch the GitHub release' changelogs and display them somewhere on an unobstrusive modal on the site, that way users are kept updated on new features & bug fixes, since I don't think most will be watching the GitHub releases page (cc @drewstone thoughts on this?)

[yuri-xyz]

@AtelyPham Mind if I take a shot at this one? 👀

[AtelyPham]

This is part of the work on upgrading Nx to v19, which I'm currently working on. After upgrading to Nx v19, it will be easier to automate the deployment process. I will get back to this after submitting the PR for upgrading to Nx v19, which should be completed around today or tomorrow.