Devdocs: Pipline deployment definition is unclear

Created on 2 Sep 2020  路  11Comments  路  Source: magento/devdocs

General issue

Description:

https://devdocs.magento.com/guides/v2.4/config-guide/deployment/pipeline/

It says:

Production system
Your live store. You should make minimal configuration changes here and no changes to:
websites
stores
store views
products
product view settings
catalog
categories
category view settings.
You should make all those types of changes in your development system.

This makes no sense to me. Does this mean, our marketing/content editors/product creators etc. should work on the development system which may often break because of development??? Then they will always come in crossfire with the developer, how does this make any sense?

And it also means that you need a developer for every tiny task like changing the product text?? because someone has to deploy the change into the production environment.

And lets say I follow this advice and make my configuration settings in development environment. How are we supposed to bring the changes to production? Aren't the configuration settings stored in the database??
Edit:
I found a documentation entry which explains that there is a file app/etc/config.php which after calling php bin/magento app:config:dump, contains all your settings which you have made in the backend. This file should be pushed into your repository (for example git).

But there are sensitive data in the file, which should not be added to your repository ... so I fail to understand the concept. Do I have to remove the sensitive data and readd it manually every time for every change??? This seems very time consuming.

2.4.x

Most helpful comment

Agreed - but these documents should reflect best practise not what people actually do. Hence why the statement "If possible" - ie it's best if you do it this way but if you can't then that's up to you.

I stand by this wording.

All 11 comments

Hi @Eddcapone. Thank you for your report.
To help us process this issue please make sure that you provided sufficient information.

Please, add a comment to assign the issue: @magento I am working on this


We should clarify that this is defining what a production server is and it is not declaring a process. The "Production" definition needs clarification and a grammar check.

I've just read this page and that section on the Production server reads WRONG.
Yes, website and store settings can all be contained in config.php so they can be tested on Dev or Staging and then deployed to Production. But products, categories & catalog? That's always done either manually or by import on Production (or perhaps by a PIM)

This page needs to be properly looked over. Not just for wording but content. I think we need to have one of the Development team explain why it was written this way.

Also @Eddcapone -

I found a documentation entry which explains that there is a file app/etc/config.php which after calling php bin/magento app:config:dump, contains all your settings which you have made in the backend. This file should be pushed into your repository (for example git).

But there are sensitive data in the file, which should not be added to your repository ... so I fail to understand the concept. Do I have to remove the sensitive data and readd it manually every time for every change??? This seems very time consuming.

The dump does NOT extract sensitive information. It leaves it in the database. You just have all the standard settings in config.php - Sensitive ones stay in the DB also for the fact they will differ across environments (eg LIVE & TEST)

On Cloud you can set the sensitive ones in the Admin UI so they don't even get into the database.

The dump does NOT extract sensitive information. It leaves it in the database. You just have all the standard settings in config.php - Sensitive ones stay in the DB also for the fact they will differ across environments (eg LIVE & TEST)

It depends on if the configuration settings have been marked as sensitive or system-specific, if they aren't, they will get added to your config.php file. I'm pretty sure that most sensitive config values from core Magento are marked as such. But for 3rd party or custom modules it can happen that they aren't marked correctly.

There is another thing I don't understand... If I execute php bin/magento app:config:dump for example on the developer environment, then I can't edit settings in the backend anymore. So how am I supposed to make a settings change now? Can I only make the change in the file app/etc/config.php?

Part of the idea of this is to also stop unauthorised changes. You don't HAVE to use it. You could omit using it on development environments. You can even remove elements that you want people to be able to change in the admin.

On Cloud Commerce you also have the option to put settings in the .magento.app.yaml or Cloud Admin UI.

"Part of the idea of this is to also stop unauthorised changes."
This should work by setting up roles. Admins should be able to edit everything and other roles should be limited...

Well, thats a different type of discussion as this issue is all about documentation, not functionality.

But you can do both. Depends on how you want to set things up.

However, in the case of config.php the options are all there and well documented. The original reason for this issue DOES stand as the statements on https://devdocs.magento.com/guides/v2.4/config-guide/deployment/pipeline/ are unclear, confusing and detailing something no-one does (you don't 'deploy' product data and categories to production).

So before we change it, is there a way we can find out why this was written like this in the first place?

@Eddcapone @hostep

I'm thinking that that section on the Production Server should be stripped back to say -

Production system
Your live store. You should make minimal direct configuration changes here and certainly nothing that has not been tested on a Staging instance. If possible configuration changes should be made using Data Patches (https://devdocs.magento.com/guides/v2.4/extension-dev-guide/declarative-schema/data-patches.html) that have been tested on a Staging/Development instance.

I think the rest of the page seems fine - any further suggestions? I can start a PR?

@BarnyShergold, regarding:

If possible configuration changes should be made using Data Patches (https://devdocs.magento.com/guides/v2.4/extension-dev-guide/declarative-schema/data-patches.html) that have been tested on a Staging/Development instance.

I can assure you that very few people do this, it might be considered a best practise, but you often have to deal with clients or project managers who want control over configuration settings without having to bother a developer every single time when they want to change a configuration setting (yes I know Magento Cloud actually has a UI for this, but this documentation isn't Magento Cloud specific)

Agreed - but these documents should reflect best practise not what people actually do. Hence why the statement "If possible" - ie it's best if you do it this way but if you can't then that's up to you.

I stand by this wording.

Was this page helpful?
0 / 5 - 0 ratings