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

Recommendation pro active maintenance #513

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

Recommendation pro active maintenance #513

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

Comments

@phavekes
Copy link
Member

phavekes commented Dec 1, 2024

This issue is imported from pivotal - Originaly created at May 8, 2020 by bstrooband

In order to be more pro-active regarding upgrading the different components we need more insights in when we need to patch. That way we\'ll be able to respond quicker when we need to patch dependencies. That way we could decide earlier on how susceptible we are. We could determine an upgrade path. This will make sure that when a new project starts we could start right away without the need off first upgrading a lot of dependencies, which could result in a lot of maintenance when you want it the least.

Some ideas:

  • Nightly builds
  • Notifications of failing nightly builds
  • Patch Tuesdays (or at least something process-oriented)

We don't have to patch it on the patch Tuesday, but if we have at least insights in what and how we at least could decide what to do when.

We could always alter the patch Tuesdays if it isn't working for us, but at least we have a kind of starting point with this.

EB status
Personally I would like to finish Github Actions in EB first so nightly builds could be implemented there.
We could also use Slack to inform when a nightly build fails. The main reason why the Github Actions PR wasn't finished was because the removal of the application.ini needed to be done first to prevent really dirty configuration in Symfony.
see: OpenConext/OpenConext-engineblock#818

Additional ideas

  • Fail Phpunit tests on deprecation warnings (6/18/2020)
  • Remove internal bundles to allow easier upgrade (6/18/2020)
  • Remove bundles and replace by a library to prevent coupling with a framework and with other bundles. PSR7 could be a potential solution. (6/24/2020)
  • Remove the test tooling from project depency management (consider https://phar.io/) (6/24/2020)
  • Refactor the components to become real microservices instead of multiple monoliths. (6/30/2020)
  • Improve proper end to end tests in Stepup (deploy) to be able to easily upgrade or refactor dependencies. (7/2/2020)
  • Test Stepup-VM (also in dev mode) to detect a faulty VM early on (7/17/2020)

** Already implemented **

  • Remove implicit dependencies, for example Mopa was needed when utilizing bundles but it was not a dependency in Composer. (6/30/2020)
@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

@michielkodde would you share your thoughts on this? (bstrooband - May 8, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

@thijskh what\'s your view on starting nightly builds in EB with Github Actions and do you prefer a particular notification method?

(bstrooband - May 12, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

@bstrooband I think you summarized everything we discussed last week. I too think experimenting with nightly builds on Github Actions would be a good starting point. But we should also think about testing our other projects on a more regular basis. Maybe we should start out with a list of applications we should check on a regular bases (patch Tuesday). My proposal would be:
  • EngineBlock + Profile
  • Stepup Suite (mw, gw, ra, ss, gssps & bundles)
  • SP Dashboard

Less regularly, maybe monthly?

  • Lifecyle (Michiel Kodde - May 12, 2020)

@phavekes
Copy link
Member Author

phavekes commented Dec 1, 2024

@bstrooband Proposal seems great to start with. We can always change when we don\'t like it... (Thijs Kinkhorst - May 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