Re: [Catalyst] Deployment in practice
2009/10/11 Octavian Râşniţă > Thank you all for your answers. It was very helpful. > What about the database? If starting from a certain revision you need to > make some database changes (adding tables, adding/deleting some table > fields) how can we automate this? > Every database update is slightly different, so automating hasn't seemed possible. The applications includes a script to build a test database. The test database is saved in svn with each application. The test files can load this database to test against when running make test. That stays in sync with development. I also have a cron job running on a test server that does an svn checkout when the revision number changes (for branches or trunk) and runs tests against this test database. > I mean, I think that we could run a script that add some tables and remove > the unneeded fields from other tables, but if something goes wrong and we > need to go back to the previous version, we would need the records from > those fields. > The database is more complex. We create a set of change files that the DBA applies. I like hand creating these and filling them with comments on why a column is added or dropped, and the tickets they apply to. They are in svn (for a history) but also in a web app the DBA uses to track what's been applied and what is scheduled to apply. It's very rare that a release includes database changes that have to be done at the moment of pushing the new version. Schema changes happen first. That is, the database is ready for the new features before the application is pushed. Sometimes constraints have to be added in after pushing the release. Bigger changes require a service window, of course. In those cases I have created a script that makes the database changes, populates tables and runs tests. Once changes are in the database tests can be run against a snapshot of the production db instead of the test database. I'd like to have it more automated, but it seems like every database change requires something special. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deployment in practice
On 11 Oct 2009, at 11:59, Octavian Râsnita wrote: From: "dab" Thank you all for your answers. It was very helpful. What about the database? If starting from a certain revision you need to make some database changes (adding tables, adding/deleting some table fields) how can we automate this? I mean, I think that we could run a script that add some tables and remove the unneeded fields from other tables, but if something goes wrong and we need to go back to the previous version, we would need the records from those fields. What can we do in these situations? Do the database update and the tests manually? Or back-up the entire database and then test the latest version of the app? Thanks. Octavian DBIx::Class::Schema::Versioned perhaps ? Dab I don't know... Does anyone use it? I read in its POD docs that "At the moment, only SQLite and MySQL are supported.", however in the past I've seen that when creating MySQL queries from a DBIC schema, some fields were wrongly created, including the size when not needed, like date date(10), so they should be corrected manually. Because of this, I don't know if this tool can be used for do the change automaticly... (Or was this issue solved since then?) Octavian refactoring Schema::Versioned uses SQL::Translator under the hood to do its job. Work has been done to make SQL::T v1 better, and as part of this years Google Summer of Code, Justin Hunter was the internals to make it easier to fix problems. So the problems should either be fixed already, or be fixed soon. -ash ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deployment in practice
From: "dab" Thank you all for your answers. It was very helpful. What about the database? If starting from a certain revision you need to make some database changes (adding tables, adding/deleting some table fields) how can we automate this? I mean, I think that we could run a script that add some tables and remove the unneeded fields from other tables, but if something goes wrong and we need to go back to the previous version, we would need the records from those fields. What can we do in these situations? Do the database update and the tests manually? Or back-up the entire database and then test the latest version of the app? Thanks. Octavian DBIx::Class::Schema::Versioned perhaps ? Dab I don't know... Does anyone use it? I read in its POD docs that "At the moment, only SQLite and MySQL are supported.", however in the past I've seen that when creating MySQL queries from a DBIC schema, some fields were wrongly created, including the size when not needed, like date date(10), so they should be corrected manually. Because of this, I don't know if this tool can be used for do the change automaticly... (Or was this issue solved since then?) Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deployment in practice
> Thank you all for your answers. It was very helpful. > What about the database? If starting from a certain revision you need > to make some database changes (adding tables, adding/deleting some > table fields) how can we automate this? > > I mean, I think that we could run a script that add some tables and > remove the unneeded fields from other tables, but if something goes > wrong and we need to go back to the previous version, we would need > the records from those fields. > > What can we do in these situations? Do the database update and the > tests manually? Or back-up the entire database and then test the > latest version of the app? > > Thanks. > > Octavian DBIx::Class::Schema::Versioned perhaps ? Dab ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deployment in practice
From: "Bill Moseley" 2009/10/9 Octavian Râşniţă Hi, I've recently started to use Mercurial for revision control and the pages regarding the deployment of a Catalyst app from the Catalyst wiki also help me very much, but I still don't know what would be the best method for uploading the files to the server. How do you do it? Archive the entire app an dupload to the server then change the permissions of the files and folders there? Or upload the modified files one by one? Or generate a tarball on each revision and unarchive and make, make test it on the server? I have a script on a build server that does an svn export of a specific branch and version (or latest trunk if no version specified). The script then runs the test suite, runs the "build" scripts that generate "minified" css, javascript, and anything else that prepares the package such as create a meta file with build info, and then builds a tarball named after the reversion. Also, a symlink is created as "latest" on the build server. Then on target machines (testing, staging, and production) I have a "push" script that fetches the tarball (based on a specific version or "latest"), untars it on the machine. It's untarred into a directory named after the revision it came from. Tests are run that verify that it can talk to whatever it needs (database, services). Then do a graceful stop of the existing server, move symbolic links, start the server back up and then use wget to validate a number of test URLs. Depending on the update some servers may get pulled out of the balancer before upgrading to do it in stages. Pushing a previous version will just update the symlinks if they revesion exists. Not perfect but seems to work ok for now. Thank you all for your answers. It was very helpful. What about the database? If starting from a certain revision you need to make some database changes (adding tables, adding/deleting some table fields) how can we automate this? I mean, I think that we could run a script that add some tables and remove the unneeded fields from other tables, but if something goes wrong and we need to go back to the previous version, we would need the records from those fields. What can we do in these situations? Do the database update and the tests manually? Or back-up the entire database and then test the latest version of the app? Thanks. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
