A reusable Django app that configures your project for deployment

Overview

django-simple-deploy

This app gives you a management command that configures your project for an initial deployment. It targets Heroku at the moment, but could be expanded to target other platforms as well.

If you have a relatively simple Django project that runs locally, you can deploy your project in a few short steps. The only change you'll need to make to your project is to add this app to INSTALLED_APPS.

Prerequisites

If you haven't already done so, install the Heroku CLI and make sure you're using Git to track your project.

Make sure your project is running in a virtual environment, and you have built a requirements.txt file with the command pip freeze > requirements.txt. (Other dependency management systems should be supported shortly.)

Quick start

If you've met the prerequisites, you can deploy your project using the following steps:

(venv)$ pip install django-simple-deploy

Now add simple_deploy to INSTALLED_APPS.

The following commands will deploy your project:

(venv)$ heroku create
(venv)$ python manage.py simple_deploy
(venv)$ git status                               # See what changes were made.
(venv)$ git add .
(venv)$ git commit -am "Configured project for deployment."
(venv)$ git push heroku main
(venv)$ heroku run python manage.py migrate
(venv)$ heroku open

After running this last command, you should see your project open in a browser. :)

Detailed steps

Since this project only focuses on Heroku at the moment, you'll need to make a Heroku account and install the Heroku CLI. Heroku lets you deploy up to five projects for free. Projects that are deployed on a free account "go to sleep" when they're not being used, but there's plenty of uptime to practice the deployment process before you need to pay for hosting.

Heroku uses Git to manage the deployment process, so you'll need to install and use Git for version control if you're not already doing so. It's beyond the scope of these instructions to provide an introduction to Git, but if you're not using version control yet you really should run through a basic tutorial before focusing on deployment. It's also a good idea to commit all of your own changes before starting this deployment process. That way you can easily go back to your non-deployment state if anything goes wrong, and you can also see the specific changes that are made in preparing for deployment.

Each Django project quickly ends up with its own set of specific dependencies. These include a specific version of Django, and any number of other libraries that you end up using in a project. These dependencies need to be managed separate from any other Django project you might have on your system, and separate from any other Python project you work on. There are a number of approaches to dependency management. For the moment, this project assumes that you have a requirements.txt file that lists your project's depencies. If you're working in a virtual environment, you can generate this file with the command pip freeze > requirements.txt. Make sure you re-run this command any time you install a new package to your project.

For the deployment process, work in an active virtual environment in your project's root folder. You can install django-simple-deploy with Pip:

(venv)$ pip install django-simple-deploy

You'll need to add the app simple_deploy to INSTALLED_APPS in settings.py. This is a stripped-down app that makes the management command manage.py simple_deploy available in your project.

Now run:

(venv)$ heroku create

This creates an app for you on the Heroku platform. You'll get a URL for your project, such as salty-river-90253.herokuapp.com. Heroku will also establish a connection between your local project and the Heroku app.

The following commands will configure your project for deployment to Heroku. It's a good idea to run git status after configuring for deployment, so you can review the changes that were made to your project in preparing for deployment.

(venv)$ python manage.py simple_deploy
(venv)$ git status
(venv)$ git add .
(venv)$ git commit -am "Configured project for deployment."

Now your project should be ready for deployment. To configure your project, simple_deploy does the following:

  • Sets an environment variable on the Heroku server called ON_HEROKU, that lets the project detect when it's being run on the Heroku server. This allows us to have a section in settings.py that only applies to the deployed version of the project.
  • Adds django-simple-deploy to requirements.txt.
  • Generates a Procfile, telling Heroku what process to run. This is the production version of manage.py runserver.
  • Adds gunicorn, dj-database-url, psycopg2, and whitenoise to requirements.txt. These packages help serve the project in production, including managing the production database and serving static files efficiently.
  • Makes sure the ALLOWED_HOSTS setting includes the URL that Heroku created for the project.
  • Modifies settings.py to use the production database.
  • Configures the project to use whitenoise to manage static files such as CSS and JavaScript files.

If you want to see the changes that were made, run git status and take a look at the files that were created or modified after running manage.py simple_deploy. Also, if you're curious to see the code that generates these changes, you can see the simple_deploy.py code here.

The remaining commands will push your project to Heroku, set up the database on Heroku, and open your project in a browser:

(venv)$ git push heroku main
(venv)$ heroku run python manage.py migrate
(venv)$ heroku open

Heroku assumes you are pushing your project from a main or master branch. If you're pushing from any other branch, you'll need to run a command like git push heroku test_branch:main. This pushes your test branch to Heroku's main branch. See the section "Deploying from a branch besides main" on Heroku's Deploying with Git page.

Ongoing development

After your initial deployment, you shouldn't need to run the simple_deploy command again. If you make changes to your project and want to push them to Heroku, take the following steps:

  • Commit your changes locally.
  • Run git push heroku main.
  • If you made any changes to the database, run heroku run python manage.py migrate.

There's a lot more to know about deployement, so see the Heroku Python documentation and start to get familiar with the parts of it that are relevant to your project.

If it doesn't work

If anything doesn't work, this project will try to tell you what to do in order to deploy successfully. If it doesn't work and you think it should, feel free to open an issue. If the deployment fails and you want to undo all of these changes, you should be able to check out your last commit before starting this process and pick up your deployment efforts from there. You can also uninstall this package with the command pip uninstall django-simple-deploy. If you do this, make sure to remove simple_deploy from INSTALLED_APPS.

Contributing

If you want to contribute to this project, feel free to open an issue and share how you'd like to help.

A great way to get started is to clone the project and run the integration tests. See the current testing documentation to get started.

Good luck, and please be mindful

Web apps have been around for a while now, and many people take them for granted because we've seen so many silly projects. But the power of a web app has never been diminished; if you have an idea for a project and you know how to build an app, you can share your idea with the world and see if it goes anywhere.

Every project that gains traction has an impact on people's lives. Many have unintended consequences, and some of that can not be avoided. If your project is gaining traction, please be mindful of the positive and negative impact it can have on people, and do what's needed to make sure it's a net positive in the world. :)

Comments
  • issue with: python manage.py simple_deploy --automate-all

    issue with: python manage.py simple_deploy --automate-all

    What do I do now?

    PS C:\Users\Jesper\Documents\jq Code\cs50w\wiki> & "c:/Users/Jesper/Documents/jq Code/cs50w/wiki/venvwiki/Scripts/Activate.ps1"
    (venvwiki) PS C:\Users\Jesper\Documents\jq Code\cs50w\wiki> python manage.py simple_deploy --automate-all
    Configuring project for deployment...
    Automating all steps...
      Targeting Heroku deployment...
    Configuring project for deployment to Heroku...
    
    The --automate-all flag means simple_deploy will:
    - Run `heroku create` for you, to create a new Heroku project.
    - Commit all changes to your project that are necessary for deployment.   
      - These changes will be committed to the current branch, so you may want
        to make a new branch for this work.
    - Push these changes to Heroku.
    - Run the initial set of migrations to set up the remote database.
    - Open your deployed project in a new browser tab.
    
    Are you sure you want to do this? (yes|no)
    yes
      Running `heroku create`...
    Traceback (most recent call last):
      File "manage.py", line 21, in <module>
        main()
      File "manage.py", line 17, in main
        execute_from_command_line(sys.argv)
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\django\core\management\__init__.py", line 425, in execute_from_command_line
        utility.execute()
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\django\core\management\__init__.py", line 419, in execute
        self.fetch_command(subcommand).run_from_argv(self.argv)
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\django\core\management\base.py", line 373, in run_from_argv
        self.execute(*args, **cmd_options)
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\django\core\management\base.py", line 417, in execute
        output = self.handle(*args, **options)
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\simple_deploy\management\commands\simple_deploy.py", line 64, in handle
        self._parse_cli_options(options)
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\simple_deploy\management\commands\simple_deploy.py", line 88, in _parse_cli_options       
        hd.deploy()
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\simple_deploy\management\commands\utils\deploy_heroku.py", line 27, in deploy
        self._prep_automate_all()
      File "C:\Users\Jesper\Documents\jq Code\cs50w\wiki\venvwiki\lib\site-packages\simple_deploy\management\commands\utils\deploy_heroku.py", line 68, in _prep_automate_all 
        output = subprocess.run(['heroku', 'create'], capture_output=True)
      File "C:\Python38\lib\subprocess.py", line 489, in run
        with Popen(*popenargs, **kwargs) as process:
      File "C:\Python38\lib\subprocess.py", line 854, in __init__
        self._execute_child(args, executable, preexec_fn, close_fds,
      File "C:\Python38\lib\subprocess.py", line 1307, in _execute_child
        hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
    FileNotFoundError: [WinError 2] Den angivne fil blev ikke fundet```
    opened by qvisty 17
  • Deploy to Azure manually

    Deploy to Azure manually

    Azure seems like a strong candidate for a second platform to support, because I believe it has a CLI and a reasonable free tier. Automating the DB may be an issue, but perhaps SQLite will work? We'll see, I've never used Azure.

    opened by ehmatthes 17
  • Update unit tests

    Update unit tests

    Many new issues have been opened after some exposure at Djangocon. Most of these issues should have failing tests written before addressing the relevant bug. It's worth cleaning up the unit tests before adding more tests. There was a brief period where unit tests were failing, I believe that was when the sample project was not fully updated.

    • [x] Document current unit test structure in this issue thread.
      • [x] Sort issue of running unit test, looking at tmp project and seeing tests pass but not seeing modifications. (Not conclusive about previous issue, but much clearer understanding of current behavior, and grounding for troubleshooting any issues that come up with unit tests.)
    • [x] Outline what we want to accomplish in the unit test suite.
      • [x] Test the CLI, without touching a project.
      • [x] What kinds of projects do we want to test against?
      • [x] What versions of Django do we want to test against?
      • [x] What artifacts of older versions do we want to test against? ie, see #175
      • [x] How will we manage testing multiple dependency management approaches?
      • [x] Can tests be parallelized?
    • [x] Restructure unit tests.
      • [x] Move platform-agnostic tests to a dedicated directory, even if one file per directory.
      • [x] Move platform-specific tests to their own directory, even if one file per directory currently.
      • [x] Consider moving shell scripts to a specific directory, if they don't fit cleanly into one of the above directories.
      • [x] Make a dedicated test module for invalid CLI calls.
      • [x] Support a cleaner syntax for testing a single platform, ie pytest fly_io or pytest --platform fly_io. (Final: pytest platforms/fly_io/)
      • [x] Reuse the same test project for all test modules, including all the different platforms.
      • [x] Make a quick assessment of how easily pytest-xdist could be used to start parallelizing tests. (Definitely not needed at this point; all tests pass quickly after initial setup work is done.)
    • [x] Document unit tests on RtD. (Remaining tasks moved to #7.)
      • [x] Document how to run unit tests on RtD.
      • [ ] Document how to extend unit tests?
      • [x] Use this documentation to start unit tests for fly_io.
      • [ ] Document goals of unit testing.
      • [x] Document how the structure of the unit tests support meeting these goals.
      • [x] Include references to relevant parts of pytest docs.
      • [ ] List expectations for unit tests for a new platform: test invalid calls, test idempotency, test configuration.
    • [ ] Resolve a recently opened issue using unit tests appropriately, to verify that the unit test structure supports good bug squashing practice. (This will be fun, and no need to keep this issue open for this task.)
    testing stability 
    opened by ehmatthes 13
  • Support poetry for all three existing platforms

    Support poetry for all three existing platforms

    The proof of concept work for Heroku originally included support for requirements.txt, Poetry, and Pipenv. When the focus shifted to other platforms, most of the work focused on requirements.txt. One of the key pre-1.0 tasks is consistent support for multiple package management approaches.

    • [x] Make sure Heroku deployments still support Poetry.
    • [x] Make sure Platform.sh deployments support Poetry.
    • [x] Make sure Fly.io deployments support Poetry.
    • [ ] Make any infrastructure changes that make it more efficient to support multiple package management systems.
    • [ ] Make an efficient way to handle unit testing for requirements.txt and Poetry across all three platforms. (This should double the overall number of tests being run, without doubling the time it takes to run tests.)
    • [ ] Update integration tests; currently the value of poetry_cmd is a hard-coded path on my system.
    • [x] See #137. (Implemented more specific check for poetry.)
    • [ ] Update docs as needed.
    • [ ] Merge, test, release.
    • [ ] Make a matrix about 1.0 support progress.
    • [ ] Run the pieces I'm touching in this work through Black.
    • [ ] Make sure all code I'm touching has good docstrings.
    • [ ] Announce.
    dependency management 
    opened by ehmatthes 11
  • Support platform.sh

    Support platform.sh

    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:

    • [x] Create a deploy_platformsh.py file in utils/.
    • [x] Add platform_sh as an optional target in simple_deploy.py.
    • [x] Add a confirmation that this is in "proof of concept" phase.
    • [x] Adapt one of the deploy_xx.py scripts to target platformsh:
      • [x] Add .platform.app.yaml to project root.
      • [x] Add .platform/routes.yaml to project root.
      • [x] Add .platform/services.yaml to project root.
    • [x] Destroy my existing project and resources.
    • [x] Look at the platform create command.
    • [x] Build a recipe where simple_deploy does all of the configuration, and we do the push.
    • [x] Write unit tests.
    • [x] Write integration tests (be aware of 2 projects per day limit).
    • [ ] Come back later for any attempt at --automate-all.
    • [x] Update documentation
      • [x] 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.
    opened by ehmatthes 11
  • Restructure CLI args

    Restructure CLI args

    All of simple_deploy's CLI args are currently defined in add_arguments(). They are organized by platform-agnostic and platform-specific groups, but not through code. This makes testing arguments difficult; for example, it's hard to write an automated test that easily validates that all arguments provided work for the given platform.

    There are some argument combinations that will have to be tested manually. But we can probably gain a lot by refactoring arguments in a way that groups them logically. For a simple example, imagine a dict of platform args as keys, where each value is a list of arguments that are valid for that platform:

    {"platform_sh": ["--deployed-project-name", "--region"]}
    

    One challenge in this is how to handle arguments that are common to multiple platforms, but have different defaults on each platform.

    • [x] Move current CLI implementation to a separate module.
    • [x] Specify the guiding principles in designing the API, in the formal developer docs. (Start an ADR)
    • [x] Propose a strategy for building out a larger API (ie, one that could support 10 platforms); reference supporting libraries, and exemplars. (No further documentation needed than what's here, and in ADR.)
      • [x] ie, should we be using Click? (Probably, because it formalizes the CLI, people tend to be familiar with Click, and it has a large community to support long-term stability.)
    • [x] Describe how such an API would be tested efficiently. (No further work necessary at this point, enough testing has been started.)
    • [x] Make sure the structure supports auto-documentation, at least for reference documentation and a --help flag. (Help is cleaned up, and auto-documentation doesn't really exist in any way I want to use.)
    • [x] Rephrase each help message as a statement about what the option does, if it's currently phrased as a question.
    • [x] Finish grouping current arguments.
    • [x] Make sure the output of simple_deploy --help is clear for all current args.
    • [x] Document final output of simple_deploy --help after this issue's work.
    • [x] Add a unit test that checks for the expected output of simple_deploy --help.
    • [x] Document the CLI.
      • [x] Mention default BaseCommand args.
      • [x] Mention testing args.
    • [x] Delete CLI related page from old_docs/?
    • [x] Add a page to Maintaining about updating RtD docs.
    • [x] Consider using Black on cli.py, to start enforcing consistency on all project files.
    • [x] Test
      • [x] unit tests
      • [x] integration test: fly_io config mode
    • [x] Merge & Release.
    • [x] Document most helpful tabs.
    api stability 
    opened by ehmatthes 9
  • Clean up dependency management work

    Clean up dependency management work

    Originally, work related to dependency management was done with only Heroku in mind. That work is different on other platforms, and it's much clearer now how to approach this efficiently. See #197, #198, #200.

    • [x] Identify the dependency management approach in simple_deploy.py, but let all other work related to this be handled by platform-specific scripts.
      • [x] This probably means changing the using_pipenv etc to a single attribute such as pkg_manager, with values such as "req_txt", "poetry", and "pipenv".
    • [x] Update poetry support to use poetry explicitly where possible.
      • [x] Fly.io (#203)
      • [x] Platform.sh
    • [x] Other poetry tasks
      • [x] Update integration tests; currently the value of poetry_cmd is a hard-coded path on my system.
    • [x] Update pipenv support on each platform.
      • [x] Heroku
      • [x] Fly.io
      • [x] Platform.sh
    • [x] Address this task in #92. (No, come back to this after windows support, or when I just have time to run some repeated tests.)
    • [x] Unit test all dependency management approaches. (#205)
      • [x] This should be a parametrized test approach, with a flag passed to the script that resets the sample project.
    • [x] Notate open tabs.
    • [x] Update docs as needed.
    • [x] Make a matrix about 1.0 support progress.
      • [x] dependency management systems
      • [x] operating systems
      • [x] stable, non-preliminary status for each platform
      • [x] friendly summary
    • [x] Merge, test, release.
      • [x] before release:
        • [x] heroku poetry
        • [x] fly pipenv
        • [x] platform.sh req_txt
      • [x] merge
      • [x] release (0.5.14)
      • [x] after release:
        • [x] heroku req_txt
        • [x] fly poetry
        • [x] platform.sh pipenv
    • [x] Announce.
    dependency management 
    opened by ehmatthes 8
  • Unit test all dependency management approaches

    Unit test all dependency management approaches

    Right now all unit tests assume the local project is using a bare requirements.txt file. Implement an efficient approach to unit testing all three currently-supported dependency management approaches: bare requirements.txt (req_txt), Pipenv (pipenv), and Poetry (poetry).

    This should roughly triple the number of unit tests. Right now there are 24 tests, and they run in about 20s. There should be about 60 tests run when this ticket is finished, and the test suite should still run in under a minute.

    • [x] First attempt: try parametrizing the reset_project() fixture.
    • [x] Pass all unit tests, for all package managers. 24 tests ~20 seconds -> 90 tests ~30 seconds. :)
    • [x] Note open tabs.
    • [x] Update documentation.
    • [x] Move relevant tasks to other issues.
    testing dependency management 
    opened by ehmatthes 7
  • Support Pipenv across all existing platforms

    Support Pipenv across all existing platforms

    Similar to #197, make sure Pipenv is supported across the three currently-supported platforms.

    • [x] Support Pipenv on Heroku.
    • [x] Support Pipenv on Fly.io.
    • [ ] Support Pipenv on Platform.sh. #200
    dependency management 
    opened by ehmatthes 7
  • Consider logging deployment steps

    Consider logging deployment steps

    This command doesn't change the user's project too much, but it's important they understand the changes that are made if they're going to maintain the deployment. Also, there's a lot of useful information that's generated and summarized in the configuration process.

    Consider an option to log the output of the configuration process. This should probably be placed in project_root/notes_simple_deploy, and this directory should probably be added to .gitignore by default.

    This would probably be implemented with an arg like --use-log or --log-output. Then probably want a command like --clear-logs, even though people could just clear the directory.

    The log could also make a separate file that just contains a short but less technical summary of what was done, and any suggestions we can make about how to continue maintaining or securing the deployment.

    • [x] Bring any items from #7 into this issue, ie padding third party output.
    documentation 
    opened by ehmatthes 7
  • Support Poetry on Fly

    Support Poetry on Fly

    I believe fly deployments fail on the restructure_pkg_man branch right now, because we no longer generate a requirements.txt file in simple_deploy when using Poetry, and the fly deploy script is doing nothing to respond to poetry specifically.

    • [x] Run fly poetry integration test, expect to fail.
    • [x] Write an add_poetry_package() method for simple_deploy.py.
      • [x] Consider a group called deploy, and make these requirements optional so they're not required for local builds.
    • [x] Make a poetry version of Dockerfile.
    • [x] Make a poetry version of fly.toml, if needed. (not needed)
    • [x] Pass integration tests. (Commit 820bcee147b9b9c605ecd95b4219e2f1dbc44453 passes.)
    fly.io poetry 
    opened by ehmatthes 6
  • Ensure consistent support across all three OSes

    Ensure consistent support across all three OSes

    During the initial proof of concept work that focused on Heroku, I made sure it worked for all three package managers, across all three OSes. I haven't touched Windows or Linux in a long time, so I doubt simple_deploy works on all three OSes.

    • [ ] Windows
      • [ ] Heroku
      • [ ] Fly.io
      • [ ] Platform.sh
    • [ ] Linux
      • [ ] Heroku
      • [ ] Fly.io
      • [ ] Platform.sh
    • [ ] Merge
    • [ ] Release
    • [ ] Test
    • [ ] Announce
    Windows Linux 
    opened by ehmatthes 0
  • Use pytest for integration tests

    Use pytest for integration tests

    One of the reasons I haven't done this previously is wanting to keep integration testing separate from unit tests. But pytest really does offer much needed structure for integration testing.

    I don't want people to end up running pytest at the root level, and accidentally trigger both unit tests and integration tests. This should be prevented by having a root-level conftest.py that exits when pytest is run at the root level. It can generate a message telling people to cd into either unit_tests/ or integration_tests, and then issue their testing command.

    See also #162.

    • [ ] Add a root-level conftest.py file that prevents root-level use of the pytest command.
    • [ ] Restructure integration tests using pytest.
    • [ ] Clarify the distinction between testing the deployment process, and running functionality tests against the deployed project.
    • [ ] Fix the issue with testing DEBUG against the local version of the project.
    testing 
    opened by ehmatthes 0
  • [New platform support]: Cloud Run

    [New platform support]: Cloud Run

    Platform

    Cloud Run

    Your connection

    Senior Developer Relations Engineer at Google Cloud

    Rationale

    Django has been supported on Google Cloud since the first DjangoCon, and Cloud Run is the latest generation of this technology.

    I personally have been working towards helping folks on Google Cloud run Django, but I'd love to be able to flip that on it's head, and help Django folks run on Google Cloud :)

    Since Google Cloud is Infrastructure as a Service, there will be a few more products in play that will help with different parts of the deployment (Cloud SQL for the database, Secret Manager for secrets, etc). These will be described as we go.

    CLI arguments

    Not mandatory but: database specs

    A minimum size postgres database in Cloud SQL has a minimum cost, but it is also small enough that it takes longer than other platforms so far just to provision the initial database (for smaller Django installations, this size of database runs fine).

    Either bumping the minimum database size, or providing a way to adjust this, will make for a faster deployment, but a larger minimum cost.

    Quick Start: Configuration-only deployment

    • Create a Google Cloud project
    • Enable billing
    • gcloud auth login

    Technical notes

    • settings.py:
      • adding the service URL to ALLOWED_HOSTS
      • whitenoise configuration
      • database_url based on envvar (provided by Secret Manager while running on Google Cloud)
    • Procfile
      • create or update the Procfile, providing commands for deploying, migrating, and collectstatic[0]
      • possibly also createsuperuser, and other admin commands
    • cloudbuild.yaml
      • a configuration file to run steps in Cloud Build (CI/CD)

    [0] https://cloud.google.com/blog/topics/developers-practitioners/running-database-migrations-cloud-run-jobs

    Authentication issues

    As long as the user is logged into gcloud with their user account on their selected project, they will have the Owner role, which enough permissions to create all the elements on that project

    Implementing support for --automate-all

    Yes, a fully automated deployment is possible, by encoding it all into that cloudbuild.yaml.

    Followup support

    Using cloudbuild.yaml!

    Either directly: gcloud builds submit

    Or, if we create a Cloud Source Repo (private Git repo), a git push to the main branch could trigger this for us (though this would be a Cloud Build trigger that fires separately, rather than a git server hook event, meaning you wouldn't get deployment output to the terminal without an extra step. (There are ways around this :) )

    Ongoing maintenance

    👋

    I own samples that do their own periodic testing, so I can setup something like this for this new platform.

    feature request 
    opened by glasnt 37
  • Setup Basic CI

    Setup Basic CI

    Alright, here's what I have so far as an ok starting point.

    The workflow runs 60 (!) jobs in parallel and takes around 10 minutes to run through all the job matrix possibilties. At the end, there's an upload artifact step that uploads the snapshot of the test project after the test run, so that should help with debugging problems on the various OSes/Platforms/Python versions.

    Runs the unit tests in each of these environments:

    • OS: MacOS, Windows, Linux
    • Python: 3.7, 3.8, 3.9, 3.10, 3.11
    • Platforms: Agnostic, Fly.io, Heroku, Platform.sh

    I've had the best luck with the Mac tests passing, though only Python 3.9+. All the other platform, os, and python version combinations have various failures.

    Creating this draft PR to get some feedback. Have I gone too far? Am I drunk with CI power?

    opened by joshuadavidthomas 5
  • Auto-added dependency is unpinned

    Auto-added dependency is unpinned

    Deploy to fly.io failed with

    #8 18.12 Collecting dj-database-url
    #8 18.12 ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    #8 18.12     dj-database-url from https://files.pythonhosted.org/packages/4c/e7/c44c0088ed3d7a938c6509288c139e0c9eb45840c83c04cad74c19951910/dj_database_url-1.0.0-py3-none-any.whl (from -r /tmp/requirements.txt (line 362))
    ``
    
    In my requirements.txt I see that simple-deploy has added this:
    
    `dj-database-url               # Added by simple_deploy command.`
    
    IOTW simple-deploy has added an unpinned dependency, but the install process requires it to be pinned.
    
    Before completing the test run:
    - What dependency management system are you using?
    venv / requirements.txt / pip-compile
    - Which platform are you targeting? fly.io
    - Repo:
    https://github.com/shacker/gtd
    
    bug stability dependency management test run 
    opened by shacker 1
  • Update contributing docs

    Update contributing docs

    Post-DjangoCon, people are interested in checking out this project and possibly contributing. Conversations at djangocon helped clarify how just about anyone can help, and writing that up soon is important. See also #142 and #112.

    • [ ] Write up contributing docs on rtd.
      • [x] Write an overview page.
      • [x] Write a "documenting a test run" page.
      • [x] Make an issue template for documenting a test run.
      • [x] Make a standalone repo with a simplified copy of the sample project, to facilitate people's first run-through of simple_deploy. Remove all dependency management files except requirements.txt, and only post the non-nested version. Done, see repo.
      • [x] Run through the test_run.md directions once.
      • [x] Write the 'using your own account' page.
      • [x] Write more categories, with brief directions about how to jump in.
      • [x] Make a discussion about idempotency.
      • [x] Setting up a development environment.
      • [ ] Write up the "supporting a new platform" page. #145
      • [ ] Next contributing steps: roadmap, 1.0 criteria, stability matrix.
      • [ ] Make a "first issue" label?
    • [ ] Add a test for documentation. The first test should verify that the contents of requirements.txt in the standalone project matches the requirements.txt file in this repo's test project.
    • [x] Update main README file.
    • [ ] Update code of conduct.
      • [ ] Move to an appropriate place in the RtD docs.
      • [ ] Add a clear way to act on CoC issues. See here.
    • [ ] Review all of this documentation.
    • [x] Make a PR and merge to main; no need to make a new release.
    • [ ] Update changelog.
    • [ ] Introduce myself on Introductions thread.
    • [ ] Review old_docs/, and see if any are ready for deletion.
    documentation contributing 
    opened by ehmatthes 2
Owner
Eric Matthes
Eric Matthes
A reusable Django model field for storing ad-hoc JSON data

jsonfield jsonfield is a reusable model field that allows you to store validated JSON, automatically handling serialization to and from the database.

Ryan P Kilby 1.1k Jan 3, 2023
Reusable workflow library for Django

django-viewflow Viewflow is a lightweight reusable workflow library that helps to organize people collaboration business logic in django applications.

Viewflow 2.3k Jan 8, 2023
Reusable, generic mixins for Django

django-braces Mixins for Django's class-based views. Documentation Read The Docs Installation Install from PyPI with pip: pip install django-braces Bu

Brack3t 1.9k Jan 5, 2023
Build reusable components in Django without writing a single line of Python.

Build reusable components in Django without writing a single line of Python. {% #quote %} {% quote_photo src="/project-hail-mary.jpg" %} {% #quot

Mitchel Cabuloy 277 Jan 2, 2023
Django-shared-app-isolated-databases-example - Django - Shared App & Isolated Databases

Django - Shared App & Isolated Databases An app that demonstrates the implementa

Ajai Danial 5 Jun 27, 2022
Django project starter on steroids: quickly create a Django app AND generate source code for data models + REST/GraphQL APIs (the generated code is auto-linted and has 100% test coverage).

Create Django App ?? We're a Django project starter on steroids! One-line command to create a Django app with all the dependencies auto-installed AND

imagine.ai 68 Oct 19, 2022
Django-Audiofield is a simple app that allows Audio files upload, management and conversion to different audio format (mp3, wav & ogg), which also makes it easy to play audio files into your Django application.

Django-Audiofield Description: Django Audio Management Tools Maintainer: Areski Contributors: list of contributors Django-Audiofield is a simple app t

Areski Belaid 167 Nov 10, 2022
A Django app to initialize Sentry client for your Django applications

Dj_sentry This Django application intialize Sentry SDK to your Django application. How to install You can install this packaging by using: pip install

Gandi 1 Dec 9, 2021
This a Django TODO app project and practiced how to deploy and publish the project to Heroku

ToDo App Demo | Project Table of Contents Overview Built With Features How to use Acknowledgements Contact Overview Built With HTML CSS JS Django How

Cetin OGUT 1 Nov 19, 2021
wagtail_tenants is a Django/Wagtail app to provide multitenancy to your wagtail project.

wagtail-tenants wagtail_tenants is a Django/Wagtail app to provide multitenancy to your wagtail project. You are able to run a main Wagtail Site and f

<bbr> 11 Nov 20, 2022
A beginner django project and also my first Django project which involves shortening of a longer URL into a short one using a unique id.

Django-URL-Shortener A beginner django project and also my first Django project which involves shortening of a longer URL into a short one using a uni

Rohini Rao 3 Aug 8, 2021
pytest-django allows you to test your Django project/applications with the pytest testing tool.

pytest-django allows you to test your Django project/applications with the pytest testing tool.

pytest-dev 1.1k Dec 14, 2022
django-dashing is a customisable, modular dashboard application framework for Django to visualize interesting data about your project. Inspired in the dashboard framework Dashing

django-dashing django-dashing is a customisable, modular dashboard application framework for Django to visualize interesting data about your project.

talPor Solutions 703 Dec 22, 2022
APIs for a Chat app. Written with Django Rest framework and Django channels.

ChatAPI APIs for a Chat app. Written with Django Rest framework and Django channels. The documentation for the http end points can be found here This

Victor Aderibigbe 18 Sep 9, 2022
Getdp-project - A Django-built web app that generates a personalized banner of events to come

getdp-project https://get-my-dp.herokuapp.com/ A Django-built web app that gener

CODE 4 Aug 1, 2022
Django StatusPage - App to display statuspage for your services

Django StatusPage - App to display statuspage for your services

Gorlik 1 Oct 27, 2021
A Django app that allows visitors to interact with your site as a guest user without requiring registration.

django-guest-user A Django app that allows visitors to interact with your site as a guest user without requiring registration. Largely inspired by dja

Julian Wachholz 21 Dec 17, 2022
Set the draft security HTTP header Permissions-Policy (previously Feature-Policy) on your Django app.

django-permissions-policy Set the draft security HTTP header Permissions-Policy (previously Feature-Policy) on your Django app. Requirements Python 3.

Adam Johnson 78 Jan 2, 2023
Dockerizing Django with Postgres, Gunicorn, Nginx and Certbot. A fully Django starter project.

Dockerizing Django with Postgres, Gunicorn, Nginx and Certbot ?? Features A Django stater project with fully basic requirements for a production-ready

null 8 Jun 27, 2022