Forums

When I finally get my python/django skills up enough to be willing to subject my users to them I will be using the Developer package here. I'm thinking 1 project will be for dev and another will just be a live copy of a git repo with an actual db instead of a sqlite or similar.

Is there a recommended workflow for using PA as the primary development environment? Was thinking dev project > bitbucket > live site project

That sounds like a good plan -- it's actually pretty close to the way we develop PythonAnywhere itself.

You could also consider setting up the live project repo as a remote on your dev project, with a hook set up to automatically check out the new codebase when you push to it.

Thanks Giles! Automation on pushes scares me. I like to know the precise moment when I broke something important :)

I can relate to that :-)

Followup question: What would you recommend for securing the dev site? I'd like to avoid debug screens being publicly available. Mac filters maybe?

Hmm, good question. We don't have any extra protection there -- we just have debug switched off by default and only switch it on when tracking something specific down. But perhaps there's a better way -- anyone else have any thoughts?

Maybe something for a future release.

In the same spot as the static files list on the web tab, put an allowed devices list. Anything not on that mac/ip list heading toward that project gets rerouted to /notallowed/ or blackholed or whatever you guys like.

Not a bad idea. In the meantime, a couple more solutions:

• run your dev. server in a console using python manage.py runserver, and then use SSH tunnelling to connect to it from your PC. Then, only you can see the server, via the tunnel
• better: remove sensitive information from your dev. version of the code. What exactly is it that you're so worried about people seeing, and is there a way you could have harmless "dev-only" versions of that info on your dev site, and keep the really sensitive stuff for live?

hp

actually, now that i think about it, my first suggestion will only work for consoles that happen to be on consoles-1. So don't use that!

Not that anything is super sensitive, just don't really like the idea of public facing dev when I have an actual website running the same stuff. Especially with the level and clarity of django debug screens.

Tho I do have customer information (some of which is medical in nature) that could potentially be exposed.... which now that i think about it is stupid cause I wont be using the production db...I'm not a bright man sometimes.

I'm trying to use a similar workflow where I work on the site in a development folder then deploy to a live site folder. I want to be able to privately work on development and see what my changes look like without needing to push to the live site. I have a paid account and I'm wondering what the best way is to go about this?

The best way is to set up a separate web app for each of them on different domains. I see you have a web developer account, so that should work fine. If your domain for your website is, say, mydomain.com, then you can set up one web app on dev.mydomain.com and another on www.mydomain.com. The first can have its code in, say, /home/janis/dev-site and the second in /home/janis/live-site. And if your site is database-backed, then you might want to consider having a different database for each of them too.

If you're wondering about how to set things up to push changes from dev to live, I'd be happy to give a few pointers on that too.

I think the biggest challenge I'm facing is how to manage the different dev and live sites settings while trying to have both running off the same code from the same git repo. Any pointers for pushing from dev to live while both a slightly different environments would be hugely appreciated!

So far I have considered creating a different virtualenv for the dev and live. Also I have considered conditional importing of settings.py. At some point I imagine that dev and live will probably be running off different DB backends, I imagine for performance related reasons that when the DB gets bigger then something like mysql will be preferable over sqlite3.

Also I'm wanting to have dev be visible only to me (or at the very least serve a different robots.txt to block search engines indexing it), is using something like a .htaccess the right way to do this?

The best technique we've been able to find is to put the stuff that differs into the settings, like you say. You put the stuff that's common to all environments into settings.py, and then add a line saying

from local_settings import *

...at the end. Then, you create separate files called (say) live_settings.py and dev_settings.py, which contain the per-environment settings, and then in your dev checkout you have a file called local_settings.py that just does this:

from dev_settings import *

...and then another local_settings.py in the live environment that has

from live_settings import *

You add the local_settings.py file to .gitignore so that you don't accidentally deploy dev settings to live, and it should all work fine.

Re: making dev visible only to you -- unfortunately I can't think of a good way to do that. But you can have different robots.txt files if you make that URL a Django view whose contents are dependent on the settings.

Thanks for the suggestion, I'm going to implement that now!

Another trick I have been using, Keeping "dev" site physically separate from "live" so I can have a release procedure between the two.

First, with regards to plugins or public libraries: The "dev" site uses "local source" versions of all the external (public) packages or libraries I use that need to be modified or extended for the project. I actually forked them to my own repo. Having the repos checked out to run as source means they get their own folder in my home folder, instead of "site-packages". And Python "runs" it from my home folder so any changes are detected and included. This allows me to change and test the changes in the "full site" in safety. I use Django's user access control to keep it private.

The "live" site uses standard installs from the head revision of the libraries I forked. So, back on dev I only check in changes after they are cleared for live use. But the live server won't use those changes until I update (re-install) these libraries.

For data security, while my dev and live db schemas are identical (I use South), I made a "safe" fixture of data for the dev server that does not contain only fake data. As testing progresses I occasionally update that fixture with exports of additional fake data added to the system for testing. It takes a surprising large amount of work to generate useful fake data - very tempting to just copy "real" stuff. But no, that would be a huge security and ethical no-no.

The actual project code is managed with Subversion (part of a TRAC project). There are clever CMS features I have not figured out yet. I just check-in the "dev" and "live" servers to different branches. Then use Beyond Compare to review changes between the two trees. Most files are identical. Settings.py, and dashboard.py have to be different. I could just copy all the other files over, but I like to check what changes were made to avoid copying over any "experimental" or "not working yet" changes. Plus since we are an Agile shop, I need to note which stories are affected/resolved by each change. Not to mention requirements coverage reports.....

That sounds like an excellent workflow! South, in particular, is an excellent tool, and any Django devs are reading this who aren't using it already should really take a look.