Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss creation of Stepup monorepo #517

Open
phavekes opened this issue Dec 1, 2024 · 5 comments
Open

Discuss creation of Stepup monorepo #517

phavekes opened this issue Dec 1, 2024 · 5 comments
Labels

Comments

@phavekes
Copy link
Member

phavekes commented Dec 1, 2024

This issue is imported from pivotal - Originaly created at Feb 11, 2020 by bstrooband

To speedup development I would like to discuss the creation of a Stepup monorepo. This will be only for the SA, RA, MW and GW componenets. So all GSSP's will be out-of-scope for now. There could be multiple build targets to build an artifact for the various Stepup components.

This will speed up development a lot and will give atomic versioning. The integration tests could also be moved to this repo. And maintenance will be less time consuming because an upgrade will only have to be done once.

There is currently unexpected coupling between the different components while at first this doesn't seem to be the case. So currently there is no real isolation between the components. There are also bundles used which are tightly coupled to Symfony and PHP versions so this seems to be more window dressing then a real solution to a problem.

See for example: GW

@phavekes phavekes self-assigned this Dec 1, 2024
@phavekes phavekes added this to Stepup Dec 1, 2024
@github-project-automation github-project-automation bot moved this to New in Stepup Dec 1, 2024
@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

@pmeulen, @phavekes, @michielkodde what are your thoughts on this? (bstrooband - Feb 11, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

For me SA, RA, MW and GW (especially the last two) seem very dependent on each other. I've run into issues because a change in GW required a redeploy of MW. I see no reasons for not rolling these components into a 'Stepup-Base', to make development and deployment easier. GSSP's should stay independent. (Peter Havekes - Feb 12, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

I see how this makes sense. Stepup-bundle will be included as well I presume.

Any downsides? (Pieter van der Meulen - Feb 12, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

I also see benefits from bundling the projects into one. There are a couple of things to consider:
  • Do we keep the four different code bases intact, or will they be turned into a single application with a single Composer installment? If we can do that, then we are really yielding a lot of benefit in case of security updates. But will result in possible unused packages for some applications. For example GW does not use package x, but SelfService and RA do. See examples below:
Stepup-mono
 - config
       - Stepup-SelfService
       - Stepup-RA
 - src
      - Stepup-SelfService
      - Stepup-RA
 - test
- composer.json
- package.json

or a more separated solution

Stepup-mono
 - Stepup-SelfService
     - config
     - src
     - vendor
     - composer.json
- Stepup-RA
     - config
     - src
     - vendor
     - composer.json
  • Does it make sense to use the existing Stepup-VM for this mono repo?
  • Will this make running tests against the Stepup product easier? In other words, could we move the behat tests from the Stepup-deploy environement to the mono repo?

(Michiel Kodde - Feb 12, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

I want to make clear I'm not advocating for a monolith but for a monorepo. I don't think there will be any drawbacks compared to the current situation because I don't see the code base exponentially growing in the future (git performance) and I also don't see our team growing with 100 developers or more (more knowledge of services and their interactions etc.). So that will be the second example from Michiel. After that we could decide to have a shared library or something like that but I think that would be too early to decide now.

I don't want to get too much into detail right now to keep the discussion alive but there are tools to merge multiple repos into a single monorepo while maintaining history. Also there are tools to split a monorepo into readonly standalone repo's (this is also how Symfony works regarding it's components). (bstrooband - Feb 12, 2020)

@phavekes phavekes removed their assignment Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: New
Development

No branches or pull requests

1 participant