also consider: of the 3 places: development, staging / final testing, and deployment,
some people stage by migrating / merging their existing site to a staging site, and then take their current deployment site "down" and deploy the staging site --- this is the kind of thing you _might_ want to do if you were (for example) to upgrade a major version of web2py - to ensure you don't have old files that might get in the way around any more. The operation you are doing really has a significant impact on how you'll want to do things. On May 26, 1:34 pm, Yarko Tymciurak <[email protected]> wrote: > On May 26, 1:08 pm, greenpoise <[email protected]> wrote: > > > Hmmm..I see. Tough stuff. I wonder if there is room for improvement in > > that area for web2py. Something that is transparent between the > > developer and the production site. > > Generally there are too many variables that depend on the target site > (although there might be some plugin you could make to help _your_ > particular situation, it's less likely that it would be worth the > effort to make it more generally useful.... but think about it - maybe > you'll show me to be wrong!). > > If you draw a diagram of the places, and their constraints that are > involved in deployment, you'll see what's involved. > > Some tools take your local machine development environment, and push > it directly to a "production" site. This was a workable concept for > static HTML page sites, but I don't know of anyone that does that > with dynamic sites. > > You have: > - a development "spot" > - a deployed-context test "spot" (e.g. on your server, with your db > server) > - and you have a "live" site - which you decide to either take down > (consider migrate=False, and you make changes to tables - something > has to be done) or keep running (and not take away from users > > Some things (reports, migrations) you can do most easily with a web2py > shell; some with a file transfer / sync tool; some most easily > through the web2py admin interface (I don't use it on a production > site, except in case of trouble or very unusual circumstances). > > The list gets rather large rather quickly. And how you want to > handle it depends on your audience and their site (I'd handle a blog > differently than a conference registration site, with thousands of > users ... and dollars exchanging!) > > Regards, > - Yarko > > > > > Thanks > > > Dan > > > On May 26, 1:28 pm, Yarko Tymciurak <[email protected]> > > wrote: > > > > On May 26, 11:53 am, greenpoise <[email protected]> wrote: > > > > > Oh no, I am not developing where the live data resides. But when I > > > > make changes to my application on my development environment, how do I > > > > transfer/update those changes on my production site? > > > > You have to work out a procedure that works with your production > > > environment. > > > > Typically, you will want a way to easily "undo" is anything goes > > > wrong: I use hg on my production site (and include things like the > > > databases files - i.e. table migrations - in that versioning). > > > > Then, you will want to work out a cut-over procedure: if you make > > > changes to modules, you will typically need to restart the web2py > > > server; otherwise, you can push changes to a running site (!). You > > > will probably want a staging area somewhere - either locally, or on > > > your production site - where you will have some way to ensure the > > > correct connection strings, etc. for your production site, before > > > pushing out to it. > > > > You could run your changes on your production server in a "beta" > > > server (to make sure the environment doesn't affect anything, and that > > > you have removed all your debug info, and that the correct connection > > > string changes are in effect - I like to have mine automatically > > > change on environment). > > > > Then you need some way to move the files over to the production > > > server, and finally the production instance. I use rsync, but you > > > could use a graphical system, something life filezilla. > > > > Basically, you have to work out your deployment procedure, and > > > recovery paths. > > > > Regards, > > > - Yarko > > > > > On May 26, 12:36 pm, Thadeus Burgess <[email protected]> wrote: > > > > > > You probably don't want to develop on your live data. > > > > > > To be able to migrate data the DAL includes two functions.. > > > > > > db.export_to_csv_file(open('/path.csv', 'w')) > > > > > db.import_from_csv_file(open('/path.csv', 'r')) > > > > > > So you can export your data, and then stick it on the server and > > > > > re-import it. This also has the advantage that you can use something > > > > > like PostgreSQL on your production machine. > > > > > > -- > > > > > Thadeus > > > > > > On Wed, May 26, 2010 at 9:39 AM, greenpoise <[email protected]> > > > > > wrote: > > > > > > I have web2py production and my development environment. How would I > > > > > > go for leaving the data intact in my production? Is there a way? > > > > > > What > > > > > > I did is I packedAll the project and took it to my production but I > > > > > > will keep working on it on my development environment. Is this how > > > > > > it > > > > > > should be done? > > > > > > > Thanks
