search

webksde / ddev-vscode-devcontainer-drupal-template

Drupal DDEV based development container with attached Visual Studio Code
22 stars 3 forks source link

Provide an initialization command for a simple 1:1 production copy #124

Open joshsedl opened 1 year ago

joshsedl commented 1 year ago

Still one may need an environment that reflects the prod environment 1:1, but while that sounds easy, there are very difficult points which can't be automated that simple in all aspects.

Things like:

Online settings.php (with real DB credentials!) which can't be used local and may never be changed. It may contain important secrets for the functionality. But if we add a local.settings.php file, this would mean, we're also changing the project! Different Drupal CMS configurations, folder structure, vhost, ... can't be simply assumed like in our environment. This may include folders which are outside of the regular structures (private files) Proxying files and such things can't be done, as we'd need a custom module and that would also change the installation! ... so, it's NOT trivial! We first need a clear plan and concept here, before changing the implementation in large parts! Things should be clear and easy from the end-user perspective.

And we have to decide, what's worth it, based on regular usage! Things evolve fast... and time is the currency.

joshsedl commented 1 year ago

Originally taken from https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/issues/121

joshsedl commented 1 year ago

Alternatively, we could also implement this functionality inside "drowl-init-from-existing"

joshsedl commented 1 year ago

Comment by @JPustkuchen in context of attaching VSCode Settings:

I think apart from ddev / docker / remote the correct way here is indeed to use the .vscode folder and/or .code-workspace file instead of other possible workarounds. That's also transparent! See https://code.visualstudio.com/docs/editor/workspaces

For production copies I think this should not be used by default.

Idea: perhaps instead of having -dev and -prod with different receipts, we should have smaller flags like the "ddev xdebug on" which add or remove defined parts, like vscode configurations, dev modules etc.?

When setting up the project, these commands would then be called automatically, so they can also be split cleanly.

If you like the idea @joshsedl we should perhaps have a master plan issue for these prod / dev things and the idea could be elaborated there... I just wrote it down here, as I came up with this when thinking about vscode integration into production projects like Drupal dev modules etc... so it's not only Drupal specific.

joshsedl commented 1 year ago

@JPustkuchen I think, I don't quite understand your suggestion.

In my current understanding, I think that would be too much. If we add further dev modules, extensions, etc. this will get way to big, I don't see myself using a command like: ddev drowl-init-from-existing --xdebug true --eslint true --phpstan true --intelephense true --xdebug-mode bla --enable-drupal-modules examples,admin_toolbar,abc --...

joshsedl commented 1 year ago

But I generally don't like the idea of this repository having a prod command.

I think a prod command would only make sense if we are keeping the local and remote copy in sync, without removing our dev tools locally.

JPustkuchen commented 1 year ago

@joshsedl I agree it's not that easy to understand, I think we'll have to go back a bit.

Problems to be solved:

In practice all these points would be very helpful, because it can be used a lot more flexible and transparent than only with the startup-command (which also allows to enable / disable these by flags)

As an example, if we put the functionality into features that can be enabled or disabled like this (naming is just for example):

These command would then explain themselves and ask for confirmation, before execution. For example list which modules they will install and what they will change and if it's revertable.

You could setup the production copy where you can be sure nothing is modified by our tool automatically and so it can be re-uploaded to production.

With the features you now don't have to decide at the very beginning, if this is a dev or a prod copy. It's just for convenience, if you'd like to decide front-up. You can simply run ddev drowl-feature-add vscode and the vscode folder will be copied over! Or you use sth. like ddev drowl-init --no-vscode --no-drupal-dev vs. ddev drowl-init --vscode --drupal-dev yet unclear which one to prefer via flags instead of drowl-feature-remove/add calls afterwards.

Now your prod copy couldn't be used for production upload anymore without manual cleanup... But then

This is just the expectation and I guess some receipts won't be revertable. But we can simply document this when running the -remove command and let the user know.

As a side-effect the ddev drowl-init(-from-existing) command will automatically be cleaned up, broken into pieces and more simple to understand, because the part where the Drupal dev modules are required and installed is now only a subcall on ddev drowl-feature-add drupal-dev (or similar) and can be reused!

I hope you got my point, otherwise let's just talk. The requirements from this come from daily practice so I'm sure this would make the devcontainer even more usable and flexible in real-world projects for us.