On May 26, 1:40 pm, Yarko Tymciurak <[email protected]> wrote: > 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.
whereas, with web2py incremental development (adding tables, adding controller functions, adding views) are such that your users will never likely even notice that you upgraded - it will just be added while the system is running... > > 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
