3 ms·

Ok then - a not so simple web project. 1) I can't just pull from git. The repo contains files which should not be on the production server 2) I'm using postgr

by doc4t 14y ago

Ok then - a not so simple web project. 1) I can't just pull from git. The repo contains files which should not be on the production server 2) I'm using postgres - not mysql. How do you incrementally change schemas? How do you roll back in case of failure without data loss?

debacle 14y ago
1. Like what? 2. I know, but you did ask. I wouldn't bother incrementally changing the schema for such a small project - I'd just throw the dumps in version control. I'd roll back in the same fashion. I guess we have different definitions of 'simple web project.' I'm thinking a 100-200 hour project that's going to see 5k visits per day, max. What are you thinking?
- doc4t 14y ago
  1. Like modules which are temp. disabled for instance. You could argue of course that these modules should then not exist in the production branch. Also reference images, project notes etc. 2. I could do that but I'm trying to learn how to do it properly...as in I imagine there would be a better way for this. When the DB (hopefully )grows to a considerable size then I take it this approach is not feasible. The project is ongoing and I lost track of the hours many years ago. 5K users! Ha - I wish :) I was thinking about my general project setup which is described in the initial question...I'm just wondering whether there would not be a more structure way to solve this problem.
  - mh- 14y ago
    you fork the branch and have one that is 'deployable'. every time you want to do a deployment, tag it with an incrementing version number. checkout said tag into apache's webroot. for managing migrations, I don't have specific experience w/ PG but this looks decent: http://www.liquibase.org/home http://www.liquibase.org/home
mixmastamyk 14y ago
1. Move those into another repo? Delete them afterward? 2. Use a migration tool. South is one for example that works with Django, there are many others.

by doc4t 14y ago

debacle 14y ago

1. Like what? 2. I know, but you did ask. I wouldn't bother incrementally changing the schema for such a small project - I'd just throw the dumps in version control. I'd roll back in the same fashion. I guess we have different definitions of 'simple web project.' I'm thinking a 100-200 hour project that's going to see 5k visits per day, max. What are you thinking?

doc4t 14y ago
1. Like modules which are temp. disabled for instance. You could argue of course that these modules should then not exist in the production branch. Also reference images, project notes etc. 2. I could do that but I'm trying to learn how to do it properly...as in I imagine there would be a better way for this. When the DB (hopefully )grows to a considerable size then I take it this approach is not feasible. The project is ongoing and I lost track of the hours many years ago. 5K users! Ha - I wish :) I was thinking about my general project setup which is described in the initial question...I'm just wondering whether there would not be a more structure way to solve this problem.
- mh- 14y ago
  you fork the branch and have one that is 'deployable'. every time you want to do a deployment, tag it with an incrementing version number. checkout said tag into apache's webroot. for managing migrations, I don't have specific experience w/ PG but this looks decent: http://www.liquibase.org/home http://www.liquibase.org/home

mixmastamyk 14y ago

1. Move those into another repo? Delete them afterward? 2. Use a migration tool. South is one for example that works with Django, there are many others.