Documenting a Test Run

[freiholtz]

Thank you for documenting a test run of django-simple-deploy! In the pre-1.0 phase of development, every test run is a helpful data point. For more about test runs, please see Documenting a Test Run.

Please answer any or all of the following questions. The more information you share, the more easily we'll be able to integrate your feedback into the project.

Before completing the test run:

• What OS are you using?
• Macos
• What project are you deploying? (the sample blog project, or your own project?)
• my own project
• If you're not deploying the sample blog project, can you provide a link to the project you're working with?
• https://www.pythonjobb.se/
• What dependency management system are you using?
• poetry + pyenv
• Which platform are you targeting?
• fly

After you complete the test run, please answer the following questions in a followup comment:

• What worked well?
• simple
• What did not work well?
• it was not clear enough that I have to create the app first and why should I.
• when deploying I did not get the option to select region and it wrongly planned to deploy to ams but I have closest to arn or at least it is in the same country.
• What suggestions do you have for the project based on your test run?
• option to go ahead with each step or tweek them.
• What questions do you have about the project based on your test run?
• non just wanted to try it out.

[ehmatthes]

Thank you very much for this! This is really helpful.

It was not clear enough that I have to create the app first and why should I.

Were you following the instructions here? I think it's a good suggestion to add a brief explanation why creating the app is part of a "simple" deployment process.

when deploying I did not get the option to select region and it wrongly planned to deploy to ams but I have closest to arn or at least it is in the same country.

That's definitely something to look at, and it's really helpful to hear how that goes for people not close to my region.

option to go ahead with each step or tweek them.

This is a very interesting suggestion, and a really good one to come up in the pre-1.0 phase. I've been quite intentionally avoiding the temptation to expose more and more of the underlying platform's CLI. I don't want to wrap each platform's CLI, I want to choose reasonable defaults and leave further customization to the user after the initial deployment runs. But there are probably some options that can be exposed during the initial deployment, with default options highlighted.

I think I'd want to add an option that specifies this tweaking workflow, and not push that on everyone. Three main workflows: --automate-all, the standard configuration-only run, and maybe a third option that allows tweaking.

Thanks again!

[ehmatthes]

Tasks

• [ ] Review this for any pre-1.0 tasks that should be completed.
• [ ] Review this for any post-1.0 tasks that should be completed.