Create a deploy command about cli

[grasmash]

I think that it may be outside of a defined scope for this tool.

What are we trying to accomplish? I would expect that deployment would involve the following steps:

• git add, commit, and push
• create database backup
• check out tag or branch on a given cloud environment
• run post deploy commands like cache clear or database updates

I’m not sure that any of those things make sense as the responsibility of Acquia CLI.

I’m particularly concerned about creating a strong coupling between Acquia CLI and specific composer or Drush commands. I think we should also leave it up to the user as to how they will commit changes.

At most, we could create a deploy command to do the following:

• create a database backup
• deploy a specified (already created and pushed) branch/tag to an environment
• output a message suggesting the use of cloud hooks for post deploy operations
• clear varnish caches
• offer to open site

Note that in specifically avoiding git, composer, and Drush operations.

[anavarre]

Real-life use case from an Acquia CLI user in IDEs:

• Pulled code, DB, files in the IDE
• Replaced codebase by fresh new install
• User blocked on uploading DB and files back to the Cloud Platform
• Got back to Dev Studio CLI to be unblocked

[grasmash]

OK, it sounds like you’re envisioning a different scope for this command. Are you suggesting that the command should push files and database upstream? Can you write the user story and requirements?

[aadityajshah]

I think ads deploy or a similar feature is definitely needed. For example, my current dev environment is running an older version of Drupal 8. In my CloudIDE I have created a new multi-site running Drupal 9. I should be able to push out the code to the repo, as well as update the DB as needed in this instance. Also, it should work without BLT as well

I agree that it should not necessarily be an ACLI command, but it should allow for a deploy of some sort to be implemented through the CloudIDE.

[grasmash]

For the sake of clarity, I think it might be better to do something like this:

• Rename ‘refresh’ command to ‘pull’
• Add ‘pull:files’, ‘pull:code’ and ‘pull:database’ and ‘pull:run-scripts’ commands you replace options like ‘—no-code’
• Add ‘push:database’ command
• Add ‘push:files’ command

If we add a ‘push:code’ command, I would prefer it to be non-functional and for it to simply emit a message like “Please use git to push code. If you’re using composer, ensure that you commit all required vendor dependencies to your hosting environment.”

I don’t wanna be involved in the process of building an artifact at all. That is what BLT currently does, and it something the cloud should eventually do.

[ba66e77]

This is especially important since the drush setup on Cloud IDE does not allow you push a database with something like drush sql-sync @self @cloudsub.dev. As a result there's no apparent way to get a database from a Cloud IDE instance to a Cloud environment.

[grasmash]

Yes, consider this on the roadmap.

[grasmash]

Resolved by #305.