What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hi! We are currently updating spryker features from release version 202001 to version 202009. We use

UT4U1HEHG
UT4U1HEHG Posts: 49 πŸ§‘πŸ»β€πŸš€ - Cadet
edited February 2021 in Help

Hi!
We are currently updating spryker features from release version 202001 to version 202009.
We use this approach to do the update, because we have quite a lot of changes in the Pyz namespace
https://sprykercommunity.slack.com/archives/CKJRJM5FG/p1601987134066100?thread_ts=1601901286.060500&cid=CKJRJM5FG

We also use our own composer libraries for our new features and use plugins when possible
in spryker functionality to use them instead of inheritance (for easier feature update in the future),
but anyway every new version of spryker changes the b2c skeleton heavily and is not 100% backward compatible.

In last b2c release version there are 1,013 changed files:
https://github.com/spryker-shop/b2c-demo-shop/commit/f63c94542991bf4cc812919c2452a3aefd895062

QUESTION:
Do you have any ready to use tool/solution to compare the changed files in Pyz namespace for some module,
between our shop state and last b2c version, let’s say in form of some user friendly report?

Currently we manually check the differences for every updated module in b2c skeleton for Yves, Shared, Service, Client, Zed, Glue namespaces.
And then carefully apply the changes to our shop, but it’s take a lot of time.

I know we can use some git diff tools or files comparison tools, and configure them somehow to do it.
But in this case if you changed in new b2c only spaces/formatting or annotations for hundreds of files, let’s say in php, these files will be also marked as modified,
but maybe it’s not something what we really need to update.

Comments

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 πŸ§‘πŸ»β€πŸš€ - Cadet

    The best Strategy is manual! It s take maybe ca. 2-3 days but for the Dev Lead of Project should not so complex if the whole project known.

    We have also a lot of changes in Pyz (yves, zed, etc...) and our product release merge are an huge... but the only way to be sure is just to do this manually and feature per feature and level per level... I mean start merge, apply conflicts singular, finish everything in the feature and then continue with the next one, otherwise u have more than ca. 500 file conflicts resolved and then u don't know anymore what u have to re-check etc...

  • UT4U1HEHG
    UT4U1HEHG Posts: 49 πŸ§‘πŸ»β€πŸš€ - Cadet

    Thank you Giovanni for you answer πŸ™‚
    In our case I think update can take some working weeks.

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 πŸ§‘πŸ»β€πŸš€ - Cadet

    Strange that so much time u think u need.
    Normally I suggest u to run periodically (max every 2 weeks) a composer update and migrate everything also for pyz level. Then when spryker release the product release is just a joke to migrate everything and resolve the conflicts.

    In your case maybe u didn t run any composer update since 1 year?

    Ok that release 202009.0 is great, but not du much that will take some working weeks.

    Other case that can be possible is that u have a lot of extensions not clean according spryker architecture and this can be simply also a problem if u try to make major updates.

  • giovanni.piemontese
    giovanni.piemontese Spryker Solution Partner Posts: 871 πŸ§‘πŸ»β€πŸš€ - Cadet

    And very important is to have a general know how of the whole project otherwise is a little bit difficult.

    But still important: spryker try to release always backward compatible, u have to take a precise look only in major updates ( even if your project is clean)

  • UT4U1HEHG
    UT4U1HEHG Posts: 49 πŸ§‘πŸ»β€πŸš€ - Cadet

    We had a review of our architecture from spryker side some month ago, everything was pretty good, some minor issues only.
    I think by us the problem also could be with no composer update for a long time, what you mentioned above.
    We applied only all needed security updates last year.
    Also for our current project we have a big team with a lot of devs and that’s why we need to spend more time to integrate some new features to our current shop state.

  • Andriy Netseplyayev
    Andriy Netseplyayev Sprykee Posts: 519 πŸ§‘πŸ»β€πŸš€ - Cadet

    the amount of time you will spend depends a lot on when have you updated Spryker last time + how many changes you have introduced since then + the quality of that changes. In general, planing β€œfew man-weeks” for 1 y.o. project is quite OK imo

  • Andriy Netseplyayev
    Andriy Netseplyayev Sprykee Posts: 519 πŸ§‘πŸ»β€πŸš€ - Cadet

    decent amount of tests will speed up the process - since you will be more confident that you didn’t break anything

  • Andriy Netseplyayev
    Andriy Netseplyayev Sprykee Posts: 519 πŸ§‘πŸ»β€πŸš€ - Cadet

    good luck with the update πŸ˜‰

  • UT4U1HEHG
    UT4U1HEHG Posts: 49 πŸ§‘πŸ»β€πŸš€ - Cadet

    Thank you very much Andriy πŸ™‚