>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3587161. --> Reported by: [japerry](https://www.drupal.org/user/45640) Related to !1014 >>> <h3 id="overview">Overview</h3> <p>Canvas currently suggests using the <a href="https://github.com/ddev/ddev-drupal-contrib">https://github.com/ddev/ddev-drupal-contrib</a> add-on for local development. While the commands in this add-on are helpful, its challenging for more junior developers to setup a complete environment for consistent testing. </p> <h3 id="overview">Local Dev "Suggestions"</h3> <ul> <li>Self-Contained Containerization: The environment should be self contained, only requiring the host to have a ddev compatible container platform (ie: docker), the ddev package, and git. All other tools should be accessible within the container itself. The same configuration should work on all platforms (Linux, Windows, OSX). Self-Contained containerization allows for better security* across the host machine</li> <li>One 'click' setup: Getting started should (preferably) take only a few simple steps, Any canvas specific details should be handled within these commands.</li> <li>Repeatable: The setup for one person should be the same as the other. This goes hand-in-hand with the one click setup, as once you start to have more commands, the greater the risk of divergence between environments.</li> <li>Consistent: OOTB setup should reflect that of using the module in production. Test results should mirror gitlab ci.</li> <li>Standardized: Follows practices/commands used by other drupal projects adopting ddev into their local development workflows. </li></ul> <p><em>*Security is dependent on your container host setup, but this container should not require you to run as root, mitigating issues that some package managers (like npm) can bring when executed on the host.</em></p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>The community has started rallying behind the ddev-drupal-contrib add-on, which works similar to Drupal's gitlab system. This involves placing .ddev config files within the module itself. New developers could then start up a ddev environment with canvas in minutes with one command. (literally `ddev start`)</p> <p>Since canvas has a wide range of tests and configuration, improvements here could also help the upstream ddev-drupal-contrib add-on, improving local dev experiences for other modules as well.</p> <p>For those worried that this issue could 'force' users into this architecture, fear not -- .ddev doesn't conflict with existing environments or workflows. Since I maintain so many different modules, I'm actually not going to use this! However, my setup is very bespoke for my use case, and I don't think its what the majority of people should do. </p> <h3 id="ui-changes">User interface changes</h3> <p>Update documentation to remove ddev-drupal-xb-dev references</p>