Support platform.sh

[ehmatthes]

In trying a number of platforms, platform.sh has emerged as a strong platform to target for people learning about deployment. It has a CLI and SSH capability, and the free trial does not require a credit card. That's really rare these days.

Tasks:

• Create a deploy_platformsh.py file in utils/.
• Add platform_sh as an optional target in simple_deploy.py.
• Add a confirmation that this is in "proof of concept" phase.
• Adapt one of the deploy_xx.py scripts to target platformsh:
  • Add .platform.app.yaml to project root.
  • Add .platform/routes.yaml to project root.
  • Add .platform/services.yaml to project root.
• Destroy my existing project and resources.
• Look at the platform create command.
• Build a recipe where simple_deploy does all of the configuration, and we do the push.
• Write unit tests.
• Write integration tests (be aware of 2 projects per day limit).
• Come back later for any attempt at --automate-all.
• Update documentation
  • cli_args.md
• Update Readme to discuss platform.sh at same level as Heroku.
• Add a "More about platform.sh deployments"
  • Add specific instructions for Windows users for how to run deployments. Testing on Windows could be interesting.

[ehmatthes]

Longer term tasks

These tasks go beyond the proof of concept stage.

• Consider disabling --automate-all on this platform, although I think it just doesn't have any effect right now?
• Set a more specific ALLOWED_HOSTS entry; currently using '*'.
• Consider breaking requirements into requirements.txt and requirements_remote.txt.
  • For now I'll use existing approach to adding requirements, but this approach makes more sense for any platform that supports it.
• Build support for the nested version of startproject.
  • Target deployment of the polls project!
• Rich would make this output so much more meaningful to most people.
• Write up a blog post using dsd and platform.sh to deploy the completed polls project easily.
  • Consider showing that the deployment process works whether using startproject flat or nested.
• Support --automate-all.
  • The platform create command can be run with a --quiet flag, and there are flags for everything that's prompted interactively. To see this, run platform help project:create.
  • Use Platform.sh integration test as a blueprint for implementing --automate-all.
• Write a friendly summary log file.
• What if platform create has already been called? Probably want to use that project, with confirmation from user.

[ehmatthes]

Notes

• Requires that user has platformshconfig installed.
  • pip install platformshconfig.
  • This requirement could probably be removed locally. The only thing it's needed for is to determine if settings are being evaluated in the platform.sh environment. This could probably be done with an os.environ check, and then platformshconfig could be imported inside the platform.sh-specific settings block.
  • For now, require it locally to match what their template shows.
  • platformshconfig is_valid_platform() source
• Deleted initial support_platformsh branch now that it's been merged and released, as that branch will get behind other work. Make a new branch for next phase of this work.

[ehmatthes]

Deployment attempt 1

• I had previously done some general setup when making my platform.sh account.
• Installed the platform.sh CLI
• Ran platform login
• Started with a locally working blog project.
• Ran pip install django-simple-deploy.
• Ran pip install platformshconfig.
• Added simple_deploy to INSTALLED_APPS.
• Ran python manage.py simple_deploy --platform platform_sh
• Ran git add ., git commit -am "Configured for platform.sh deployment."
• Ran platform create; answered prompts.
• Ran platform push; answered prompts.
• Works!!!

[ehmatthes]

Release

• Make a release, and try this one more time. dsd is at 0.x.x, so it's okay to push an experimental release.
• Make sure simple Heroku tests pass.
• Try once more with platform.sh.

[ehmatthes]

Final proof of concept work

• Success message needs to mention platform login, platform create.
• First run with a new account:
  • platform login
  • platform create
    • Prompts to create an organization
    • Then an organization machine name, then country
• When running platform create, it prompts for a project name. Does that have to match the project name in the configuration yaml?

[ehmatthes]

Unit tests

• Restructure unit tests so the simple_deploy command is run by the platform-specific test script.
  • I think I need to skip prompts if local_testing flag is set.
• Create a new test file that starts to test Platform.sh-specific changes to a project.
  • settings
  • .platform.app.yaml
  • .platform/routes.yaml
  • .platform/services.yaml
  • requirements
  • log files
• Update unit test documentation.

[ehmatthes]

Integration tests

• Make integration tests require a platform flag.
• Check that platform value is valid.
• Build flag for platform.sh, and have it call an empty test file.
• Write the test file, and do the actual test on a file that should fully work.
  • Build, modify, and destroy test project without deploying it.
  • Get URL from platform project:info output
  • Get project id from same call
  • Call platform url --quiet to open project
  • Set DEBUG=False in settings.
  • Deploy project, and pass sample project tests.
    • Passes all tests except DEBUG=False test (7/20/22).
  • Use project id to delete project.
  • Clean up any commented code.
  • Consider using the --local_testing flag to avoid prompts during test runs.
  • Output the temp dir location.
• Update documentation.

Working notes

• Poetry unsupported.
• Pipenv approach probably needs work.
• Probably doesn't work on Windows, outside a bash shell.
• May want to modify default region in test.
• Project per day limit really hampers work, if that's what the issue is. Try again W 7/20.
  • This seems to be the issue, I can't even create a blank project in the browser portal. Probably two projects per 24 hours or something?
• May want to build a CLI arg for --region in the platform create call.

[ehmatthes]

Update documentation, and log output

• Need to be clear about what project name to use; could have people run platform create first.

[ehmatthes]

API Reflection

Working through this issue clarifies that writing a script to support a new platform is not entirely straightforward until the API and overall approach is solidified. For example, do we expect users to run platform create before running simple_deploy, or after? In reality we should recommend one, but accommodate either. That means running project:info at the start of the Platform.sh script, and using the established name if it exists or the standard project name if it doesn't exist yet. But, we can only promise that deployment should work if it's already been run.

[ehmatthes]

• Require running platform create first.
  • If they can't, then configuration wasn't going to help.
  • What about if they made a project in the console, or it was already made? Maybe it should just be a recommendation? Maybe enforce a workflow where the project needs to have been made somehow, and needs to support appropriate information available through project:info?

[ehmatthes]

Moved all open asks to #89 and #90.