As a developer, I'd like to configure my Sitecore environment in a way that's optimal for development, so that I can have a faster development environment and an easier debugging experience.
Concept
Allow configuration of development-specific Web.config transforms and App_Config patches in the development entrypoint. Docker Tools would provide some of the essentials, but developers could add others.
Transforms/patches would be organized into folders, and the folder names could be used to enable specific patches.
It allows you to have a consistent image build for dev, test, and prod, and makes these development-only transforms transient.
Is there some way to set Web.config values purely with environment variables and configBuilders?
My POC with Section Handlers was only half-successful. It's possible for customErrors but not compilation, due to availability of the app domain during configuration load.
Why an environment variable and not a entrypoint script argument?
Seems cleaner this way, but open to input on this.
As a developer, I'd like to configure my Sitecore environment in a way that's optimal for development, so that I can have a faster development environment and an easier debugging experience.
Concept
Allow configuration of development-specific Web.config transforms and App_Config patches in the development entrypoint. Docker Tools would provide some of the essentials, but developers could add others.
Transforms/patches would be organized into folders, and the folder names could be used to enable specific patches.
Example
Why not do this in a Dockerfile?
It allows you to have a consistent image build for dev, test, and prod, and makes these development-only transforms transient.
Is there some way to set Web.config values purely with environment variables and
configBuilders
?My POC with Section Handlers was only half-successful. It's possible for
customErrors
but notcompilation
, due to availability of the app domain during configuration load.Why an environment variable and not a entrypoint script argument?
Seems cleaner this way, but open to input on this.