[policy] Create a plan for a smooth way to start real, live projects

There is no custom code in Drupal CMS trial experience.

In theory, at its simplest, I believe we have a composer.json file, a database, and a files directory. Could I download those? I know of at least one host who could let you import those 3 things through their web GUI.

I picture people being able to clone the project template into their GitHub, for example, which would come pre-configured with a CI/CD configuration that deploys to a supported host on every commit to the main branch.

I think you lost the marketer at GitHub, but if you didn't, you will surely lose them at secrets keys, access tokens, CI/CD configuration, etc...

I feel like we should at the minimum create a tool similar to WordPress' Export and Import. I assume a single or minimal database tables to XML that WP has is easier than a Drupal database, but if the flow could be similar. Having an export/import module or service in Drupal where you could export an archive of composer.json, database, files. Then the user could install a fresh Drupal anywhere and import the archive.

I think if that were the base, then enhancements like CI/CD and terminus and acli fun could be layered on that.

I know there are plans to mitigate, but I should point out that even for an experienced dev, the path to go from a local Drupal CMS install to a hosted site ready for normal git deployments if far from straightforward today. Separate from the intent of this issue, but also something we shouldn't lose sight of.

At amazee.io (and Lagoon-based hosting) our intention (currently*) is to run Drupal CMS projects in production that are almost identical in layout to ordinary Drupal Core projects - so any path to GitOps for our users would be to stand up our usual template - and export the db, config, files, and the composer files from the running site, probably via drush (which should work prod>local) - and this then should be enough to rebuild your running site locally (but there's a lot of R&D to do to see if this is indeed true, or whether there are other parts of the codebase that can be modified in Drupal CMS that we aren't across.

This is an action item for the leadership team, first to outline the ideal UX, and then over to the DA for implementation (and also comms with the eligible hosting providers to ensure they can comply with whatever spec we come up with). So if folks have thoughts they want to share, this is a good place for that, but it's already in the works!

An interesting and related point came up in the marketing meeting (minutes https://docs.google.com/document/d/1omdXvqTGP5OSBmepT6CehkAvB_UO2xAySq9X...) i.e. could we find an appropriate end user to migrate their website to Drupal CMS, by way of an early case study for use in marketing. We have a candidate in mind and this would also provide an opportunity to trial the 'low code' hosting set up and launch journey. Thoughts welcome.

Strongly agree with #3. Wouldn't it be easier to start from there and then continue simplifying for the site builders and marketers?

DDEV made it really easy to start, and has already some relevant resources for deploying you might want to check at https://ddev.readthedocs.io/en/stable/users/topics/

In theory, at its simplest, I believe we have a composer.json file, a database, and a files directory. Could I download those? I know of at least one host who could let you import those 3 things through their web GUI.

fwiw I've also been assuming the workflow would be something like this.

So from the Drupal CMS demo, you can download:

composer.json
database
files
+ config export (in case someone wants to not restore their content)

These could be 3/4 separate downloads, or one archive.

Then on the hosting side, upload those, and it deploys a site for you based on those files.

Then if you have 'deployment by git branch' the host can create a git repo and give you details, which you can then use for ddev etc.

Once someone's got that, they can also add a private github as a remote or similar, but this should be the last step rather than the first if we want to mostly keep people off the cli.

I think it would be worth (probably in a separate issue) discussing a static site generator work track/recipe and workflows to get from the demo to deploying a static site too - since that would massively expand the potential of low cost hosting options.

I can’t stop thinking about the Backup and Migrate module is a great foundation for this.