[Catalyst] Deployment in practice
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? Or something else? Thank you. 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
2009/10/9 Octavian Râşniţă orasn...@gmail.com: 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? We do a checkout of the latest version on our staging server, test everything and then rsync it to the webservers. Works like a charm. --Tobias ___ 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 Fri, Oct 9, 2009 at 7:55 AM, Tobias Kremer tobias.kre...@gmail.comwrote: 2009/10/9 Octavian Râşniţă orasn...@gmail.com: 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? We do a checkout of the latest version on our staging server, test everything and then rsync it to the webservers. Works like a charm. I have deployment branches, and then push from there. It's git, but I'd assume you can do the same in hg (though I've never used it) See: http://blog.woobling.org/2009/05/deployment-branches-with-git.html Then, you can use this post-hook script on the production machine and simply push to that repo: http://github.com/perigrin/soho-web/tree/master/hooks/post-update This works very well, and you can have that be on a deployment server/location and update the working tree of the other servers in the node. -J ___ 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: J. Shirley jshir...@gmail.com On Fri, Oct 9, 2009 at 7:55 AM, Tobias Kremer tobias.kre...@gmail.comwrote: 2009/10/9 Octavian Râşniţă orasn...@gmail.com: 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? We do a checkout of the latest version on our staging server, test everything and then rsync it to the webservers. Works like a charm. I have deployment branches, and then push from there. It's git, but I'd assume you can do the same in hg (though I've never used it) Thank you Tobias and J. For the moment I think I will use Tobias' way, because I use Mercurial only for a few days and I don't know if it supports hooks made in bash. I know that git is made in C and some perl scripts, that it is faster, much advanced than Mercurial (which is made in Python), but unfortunately it doesn't work well under Windows, and I do the development under Windows and the testing and production use under Linux... 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
2009/10/9 Octavian Râşniţă orasn...@gmail.com: 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? Or something else? I like to have a revision per code push and rsync it out. What I don't recommend is updating code directly from a repo on the server, it will get you eventually. http://blog.johngoulah.com/2009/03/code-deployment-techniques/ ___ 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] e-commerce plugins for catalysts
On Thu, Oct 8, 2009 at 11:04 PM, Devin Austin devin.aus...@gmail.comwrote: On Thu, Oct 8, 2009 at 9:01 PM, pro...@gmail.com pro...@gmail.com wrote: Hi, I am looking into how easy it might be to add basic e-commerce functionality -- a shopping cart, order, checkout system etc -- to a catalyst app. I found some very old articles on Handel - http://handelframework.com/blog/ and mango http://mangoframework.com/blog/ but I was wondering if anyone on this list has used any of those and what their thoughts are on them. Suggestions of other alternatives are also very welcome. Thanks you so very much, Check this out: http://search.cpan.org/~claco/Handel-1.00011/lib/Catalyst/Helper/Handel.pmhttp://search.cpan.org/%7Eclaco/Handel-1.00011/lib/Catalyst/Helper/Handel.pm Perhaps it'll help you and be a little more up to date. Thank you very much Devin for the link. I was also wondering if anyone has had any experience and thoughts on using Handel, Mango or any catalyst friendly e-commerce plugin in a real-world app. Any additional advice would be much appreciated. ___ 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/
[Catalyst] Re: Deployment in practice
MA == Mesdaq, Ali ames...@websense.com writes: MA Once it passes the tests the code can be merged into the MA production branch and will auto deploy. That's a great solution until someone checks a change into the production branch accidentally. As someone already mentioned, it'll happen eventually. I'm a firm believer in not using version control as a deployment tool. It's more work to create a package, deploy that to test, test, deploy *the same package* to production, but you at least know that what you tested is what's in production. Pulling straight from VC you never really have that assurance. k. -- kevin montuori ___ 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] Re: Deployment in practice
On Fri, Oct 9, 2009 at 1:18 PM, kevin montuori montu...@gmail.com wrote: MA == Mesdaq, Ali ames...@websense.com writes: MA Once it passes the tests the code can be merged into the MA production branch and will auto deploy. That's a great solution until someone checks a change into the production branch accidentally. As someone already mentioned, it'll happen eventually. I'm a firm believer in not using version control as a deployment tool. It's more work to create a package, deploy that to test, test, deploy *the same package* to production, but you at least know that what you tested is what's in production. Pulling straight from VC you never really have that assurance. A lot of these assertions are pretty much FUD. Even exporting a tarball is sourcing from version control. You're just bypassing a lot of the built-in aspects of source control and applying manual steps that can be messed up in a variety of ways. Unless it is sourced from source control in a way you can easily and programmatically detect, you really don't know what is in production outside of a tarball.You can keep an archive of tarballs, but you lose context and history... so what's the win? If something happens and you need to find out the history, what do you do? You ask version control! There are plenty of ways to manage how things get into a production branch. Then, you simply add in another layer using tags. After all, that's pretty much why tags exist, and how they're used, in every sufficiently modern system. You deploy a tag, from a branch, and everybody wins. Keep in mind that I'm not advocating (nor are the posts I linked to) running from a -managed- tree. The post-update hook I linked to keeps its own git repository to itself, it isn't share. You have to explicitly push to it to update. These things are very hard to get wrong, and they work very well. You just have to learn the tools sufficiently. -J ___ 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] Re: Deployment in practice
On Fri, Oct 9, 2009 at 3:08 PM, J. Shirley jshir...@gmail.com wrote: On Fri, Oct 9, 2009 at 1:18 PM, kevin montuori montu...@gmail.com wrote: MA == Mesdaq, Ali ames...@websense.com writes: MA Once it passes the tests the code can be merged into the MA production branch and will auto deploy. That's a great solution until someone checks a change into the production branch accidentally. As someone already mentioned, it'll happen eventually. I'm a firm believer in not using version control as a deployment tool. It's more work to create a package, deploy that to test, test, deploy *the same package* to production, but you at least know that what you tested is what's in production. Pulling straight from VC you never really have that assurance. A lot of these assertions are pretty much FUD. Even exporting a tarball is sourcing from version control. You're just bypassing a lot of the built-in aspects of source control and applying manual steps that can be messed up in a variety of ways. Unless it is sourced from source control in a way you can easily and programmatically detect, you really don't know what is in production outside of a tarball.You can keep an archive of tarballs, but you lose context and history... so what's the win? If something happens and you need to find out the history, what do you do? You ask version control! There are plenty of ways to manage how things get into a production branch. Then, you simply add in another layer using tags. After all, that's pretty much why tags exist, and how they're used, in every sufficiently modern system. You deploy a tag, from a branch, and everybody wins. Keep in mind that I'm not advocating (nor are the posts I linked to) running from a -managed- tree. The post-update hook I linked to keeps its own git repository to itself, it isn't share. You have to explicitly push to it to update. These things are very hard to get wrong, and they work very well. You just have to learn the tools sufficiently. -J ___ 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/ I'm coming in late but deploying a tag from trunk/etc and switching the production directory that nginx/lighttpd/apache is looking at is probably the coolest thing ever. You have a great deal of control when needing to roll back, and a record of all previous tags/versions. Anyway, my $0.02. -Devin -- Devin Austin http://www.codedright.net 9702906669 - Cell ___ 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] Re: Deployment in practice
On Fri, 9 Oct 2009, Mesdaq, Ali wrote: At least with the first issue you can roll back the change and get back to stable instantly. With the other issue you could be troubleshooting for a long time. But I think the OP (other poster) mentioned packages. Presumably you can roll back to an earlier package as easily as rolling back to an earlier state of the tree. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ ___ 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/
