Skip to content

Adopting Configuration as Code (CaC) using Magento

This article discusses a relatively new practice made available to Magento. We explore what CaC means and how, in conjunction with version control, it can bring great benefits to application stability.

Many merchants and agencies working with Magento will have experienced issues when changing configuration settings in Magento Admin. Such changes could invoke code under different scenarios not covered in testing plans and smaller merchants are more at risk to this particularly when issues caused might not offer obvious evidence on the front-end user experience.

Here are some key reasons why your organisation can benefit from adopting CaC practices:

  • Security - Preventing key changes to the application and promoting a higher level of auditability for access.
  • Traceability - Using version control, configuration changes can be coupled with development and ultimately make all changes traceable to both individuals and time-frames.
  • Manageability - Incorporating CaC into build and deployment pipelines means the QA process can ensure non-breaking changes.
With Magento Open Source, we don’t get the core feature of admin actions log, which is a key driver not just for accountability but ultimately to ensure configuration changes are known. Put simply, a change in Magento Admin can invoke code that might not have been tested under the exact same scenario, therefore any change could cause risk. The switch to CaC might not be something smaller merchants feel happy to support, so it’s important that the driving force can introduce this to a merchant in the best way.

This might include the following:

  • Engage with the merchant and discuss configuration settings that should be locked. Ie. Payment options.
  • Ensure that any deployment automation can facilitate CaC.
  • Ensure that configuration changes are versioned and the Operations team can manage and take ownership.

So how about CaC in Magento?

OK so there are a couple of techniques that we have come across, unfortunately, the key one offers less than desirable results for many.

bin/magento app:config:dump

This will export all the possible configuration settings into config.php. This is not ideal for many merchants, as there will be non-production settings you wish to use and also potentially, less critical configuration settings that you may wish to change easily from time to time. Eg. store opening hours or contact telephone numbers. For this reason, we generally recommend a more selective process. One example here has been adopted as the primary method of implementing CaC in a less forceful way which really brings the topic center-stage for a merchant/agency relationship so that stakeholders can take more ownership of the operational aspects of the Magento platform.

In brief, the development lifecycle involves changing configuration settings on a non-production instance, then some simple commands can capture the changes made and bake just those configuration changes into code and incorporate the changes into the work package. ZERO-1, the company behind MDOQ has adopted this practice since Magento 2.3.2 and this works well for most merchants. Currently we refer to this great article on Configuration as Code using Magento

Ideas for progression

We are considering the development of an extension that could allow easy management of configuration (paths) which should be excluded from app:config: dump, which makes for a cleaner method of baking code into config than the aforementioned article. This article is really meant to open a debate on this topic so that merchants and agencies can help all merchants form a more consistent foundation of CaC practices with Magento Open Source.