Every time a developer requires to exclude/ignore files and/or folders, in a certain git repository, the .gitignore file becomes handy. However, sometimes git will not exclude files/folders added in .gitignore. The reason is that those resources had been committed before, without being noticed by the developer. In the following example, a new file test.xml has been added, so after executing git status the display will look like this.

Fixing this issue is quite simple by simple using the CLI, just as follows:

1. Update .gitignore by adding the folder/files to be ignored, in this example test.xml will be added.

1. Add changes and commit

git add .

git commit -m “Modified .gitignore file”

1. Execute the following command to clear git cache for the whole repository

git rm -r –cached .

1. After this, when executing the git status command git will not display test.xml as an untracked file.

From this point, every change to the text.xml will be excluded/ignored.

Technology hardware and software are upgrading constantly, mostly in order to provide a better service and/or improve security, in the middle of this constant changing the PHP scripting language needs to cope with all these dynamic environments. 

Magento Cloud also facilitates changing the PHP version; providing more convenience to any DevOps team. 

When upgrading the PHP version, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct PHP version.

Adobe Commerce version	PHP version
2.3.5	7.2, 7.3
2.3.6	7.3
2.3.7	7.3, 7.4
2.4.0	7.3, 7.4
2.4.1	7.4
2.4.2	7.4
2.4.3	7.4
2.4.4	8.1
2.4.5	8.1

For changing the PHP version, the file .magento.app.yaml must be edited. For example:

Original service definition:

type: php:7.2

Updated service definition:

type: php:7.3

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Changed PHP version”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade by SSH into the environment and check the PHP version:

php -v

After confirmation, the environment can be used as normal.

By design, when the site administrator uploads a new product image, Magento will autogenerate all the image sizes and required cache folders inside the pub/media folder. After this, every time the frontend browses those images Magento will serve those cache folders, aiming for faster browsing times.

Magento Cloud architecture allows extra settings for handling those image cache folders; including the minimum persistence time on the cloud.

The .magento.app.yaml file, besides allowing to configure the PHP version, extensions, and relationships, also allows configuring how long the cache folder must persist in the cloud. Let’s consider the following example where the cache folder is being configured to be stored for at least 1 year.

“/media”:

            root: “pub/media”

         …

            expires: 1y

    …

This will assure that the cache folder will not lose any data for at least 1 year; however if after one year the environment is redeployed, it is possible that the images will not be displayed and the browse console will display a 404 error when attempting to load any product image.

For solving this issue and also, for renewing the cache folder for another year, the cache needs to be regenerated by accessing the environment via SSH and executing the following command:

php bin/magento catalog:images:resize

This command will regenerate all necessary images sizes and their corresponding cache resource inside pub/media. Also, after this, it is recommended to re-index and clean the cache.

php bin/magento indexer:reindex 

php bin/magento cache:flush

After this, all product images will be displayed normally.

Magento Commerce Cloud allows a service downgrade for any particular environment; the downgrade process is not as direct as upgrading, but it is still very convenient.

When downgrading a service, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct service version.

Service	Adobe Commerce 2.4.x	Adobe Commerce 2.3.5 ~2.3.9
elasticsearch	7.7, 7.9	6.8, 7.5, 7.7, 7.9
mysql/mariadb	10.2, 10.4	10.1 ~10.3
rabbitmq	3.8	3.7, 3.8
redis	5.x, 6.x	5.x, 6.x

The easiest way for downgrading a service is by renaming it or creating a new one in the magento/services.yaml file. For example:

Original service definition:

elasticsearch:

    type: elasticsearch:7.7

    disk: 1024

Updated service definition:

elasticsearch2:

    type: elasticsearch:6.8

    disk: 1024

After that, the services relationship must be updated in the .app.magento.yaml file. For example:

Original service relation:

relationships:

    database: “mysql:mysql”

    redis: “redis:redis”

    elasticsearch: “elasticsearch:elasticsearch”

    rabbitmq: “rabbitmq:rabbitmq”

Updated service relation:

relationships:

    database: “mysql:mysql”

    redis: “redis:redis”

    elasticsearch: “elasticsearch2:elasticsearch”

    rabbitmq: “rabbitmq:rabbitmq”

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Downgraded elasticsearch service”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade:

elasticsearch2:

    –

        username: null

        …

        type: ‘elasticsearch:7.7’

       …

After confirmation, the environment can be used as normal.

As part of its solution, Magento Cloud facilitates changing the services for any particular environment; reducing also the risks of causing a conflict within components.

When upgrading a service, its version needs to be compatible with the Magento host version. The following table can be referenced for helping to determine the correct service version.

Service	Adobe Commerce 2.4.x	Adobe Commerce 2.3.5 ~2.3.9
elasticsearch	7.7, 7.9	6.8, 7.5, 7.7, 7.9
mysql/mariadb	10.2, 10.4	10.1 ~10.3
rabbitmq	3.8	3.7, 3.8
redis	5.x, 6.x	5.x, 6.x

For instance, for Magento 2.3.7, a valid selection would be as follows:

• elasticsearch:7.7
• mysql/mariadb:10.2
• rabbitmq:3.8
• redis:5.0

For changing a service version, the file .magento/services.yaml must be edited. For example:

Original service definition:

elasticsearch:

    type: elasticsearch:6.0

    disk: 1024

Updated service definition:

elasticsearch:

    type: elasticsearch:7.7

    disk: 1024

Commit the changes and push the changes for activating a redeploy:

git add –all

git commit -m “Upgraded elasticsearch service”

git push <remote> <branch>

After redeploying open a tunnel via Magento CLI:

mgc tunnel:open

mgc tunnel:info

And check the service version for confirming the upgrade:

elasticsearch:

    –

        username: null

        …

        type: ‘elasticsearch:7.7’

       …

After confirmation, the environment can be used as normal.