Revise Epic page structure for easier maintainability

Summary

This was discussed verbally earlier in Portfolio Management team call but I'm opening up an issue to move the conversation forward.

Current structure of Epics Vue app is acting as a roadblock in rapidly adding new features or writing tests. Any changes we do to Epics app involves touching several key components which aren't written well as per our frontend guideline. This limitation has act as a major factor in throttling speed at which we could develop new features for Epics page, and on several releases, the mere time it took just to make frontend tests pass after any modifications made to Epics app was significant enough to hinder availability of feature in a specific release.

Addressing this problem will make FE development on epics ~50% faster. See https://gitlab.com/gitlab-org/gitlab-ee/issues/7164#note_93486053

Proposal

Restructuring Epics app a multiple release effort and we don't plan on scraping out current app until the new app is ready with exact feature parity. Also, it is worth mentioning that we're not scraping out everything from current app, to put some perspective of the effort, at least 30-35% of code involved in current app can be reused as it is in new structure. This is also not a visual refresh, it is just behind the scenes architectural update of the app.

Here's what I propose;

  • Schedule this issue and begin frontend work on rewriting new app in upcoming 1 or 2 release.
  • We start by developing a shell that will live in a hidden-in-production URL, this ensures that older app is still primary.
  • Once we have new app on par with current one, we scrap old app and make new one primary.

FAQ

What happens to new features we plan to develop around Epics?

Scope of upcoming features is frequently discussed in Portfolio Management call, and based on what I have found so far, most of the features are (and can be) developed isolated and then integrated into main Epics app, so this rewrite does not mean that we're cutting down on what we can add in current app. Having said that, in order for me to allocate more time working on app rewrite, I insist on not scheduling one giant feature for time being that will occupy entire development cycle for the release.

How many releases would it take for this rewrite to finish?

Based on current feature set of Epics app, it shouldn't take more than 3 releases to complete whole thing. In this 3 releases schedule, I'm also including the duration in which we make new app as primary by merging it into master and test it in dev.gitlab.org and fix any regressions that arise.

Does this rewrite need any backend help?

No. It is purely frontend work.

Will it be possible for anyone to see this new app in action before it replaces old app entirely?

Yes, I'll have a toggle that anyone can alter and make new app default.

Where can I look at current code for Epics app?

Edited by Kushal Pandya