Include CICS in Zowe Explorer Mono Repo

[jellypuno]

Should we include CICS VSC ext in our monorepo?

Open Questions:

• What are the changes that needs to make this happen?

Notes: Squad needs to vote on this

[jellypuno]

This topic needs a TSC decision. We need to identify what dos it mean to be added in the ZE core package

[jellypuno]

Goal:

• answer the questions in this issue: Create an Acceptance Criteria Doc for products what will be included in monorepo #1294
• Acceptance Criteria to add ext in the monorepo

Question:

• Are there many things required in order for the CICS ext be merge in the monorepo?
  • yarn
  • webpack
  • deployment scripts

Benefits:

• Easier development for CICS. They can quickly pick up the API changes. No need to wait for a release
• Easier to ZE dev to test their changes and how they affect extenders
• One CICD pipeline for the Zowe VSC extensions
• Version numbers are matched. Better UX.
• Standardize on code and use the same architecture. Consistent builds.
  • CICS ext is not structured well so if they are added in the monorepo then they will have more guidance and structure (code and release process). It will be more organized if added to the monorepo and part of the squad
  • The whole squad to help in the implementation.
• If an extender creates its own API then we will have a standard format or maybe add it in the ZE API and make it a common API.
• Easier project coordination between extenders and ZE.
• Shared test cases / scripts

Cons

• Learning curve for the Explorers Squad with the CICS codebase and functionalities
  • more time will be required from the team
  • issues from the OMP will be handled by the squad
• Scaling
• Issues will be mixed with ZE issues. Can be fixed by tagging but it is still confusing.
  • We could have a separate issue template for extenders

[Joe-Winchester]

At the architecture call November 16th this was discussed, and there was agreement that this was a good idea.
The concern raised was whether this would mean that the Zowe Explorer for IBM CICS extension would somehow be accidentally become part of Zowe core, however this shouldn't be the case as Zowe Explorer for FTP extension is already in the monorepo and isn't part of Zowe core so that sets precedent.
The advantages of the extension being part of the monorepo are all well described above. The biggest one I can see is how to separate issues coming from Zowe Explorer core vs. Zowe Explorer for FTP vs. Zowe Explorer for IBM CICS.

[pdubz3]

A few fairly random thoughts ...

1. Architecturally this sounds reasonable and beneficial. But I'm not sure about scalable. Is this the last such extension to warrant inclusion in the monorepo? Is it possible that some of the "cons" will be magnified down the road?
2. The benefits seem clear and obvious, but is it just a list of benefits that the team can imagine they'll gain? Or are these actually known positive outcomes that solve current problems that the team is having? In other words, are we solving existing development problems here or are we just organizing our stuff?
3. Is there a cost to doing this? If so, what's the cost? And is it "one time" or "ongoing" or both?
4. Is this time-sensitive? Is it something that would need to happen immediately? Or before V2? Or ... some other driver?
5. I'm not sure I understand all of the cons. For example, you say it will require more learning curve and more time from the team. Does that imply that just because you add an extension to the monorepo, everyone on the team instantly needs to fully understand how it works? Does this actually change responsibilities within the team?
   That's enough for now. :-)

[JillieBeanSim]

@zFernand0 will we want to close this discussion as it's moving to mono-repo with it corresponding CLI component?

[zFernand0]

Yeah, I believe this discussion can be closed 😋

[zFernand0]

As Billie mentioned,
The CICS extension will soon be deployed within a monorepo of its own, containing the CICS CLI plug-in and the CICS Node.js SDK alongside it