RE: [Catalyst] Re: Deployment in practice

2009-10-09 Thread Dave Rolsky 

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/

RE: [Catalyst] Re: Deployment in practice

2009-10-09 Thread Mesdaq, Ali 
Solving the issue of someone accidentally checking something into production 
branch is a lot easier to solve than all the problems associated with not 
having version control. To compare which do you think will be an easier issue 
to solve: Someone accidentally checking something into production branch that 
breaks stuff or someone making a change to production server with no version 
control that breaks stuff? 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.

Thanks,
--
Ali Mesdaq (CISSP, GIAC-GREM)
Sr. Security Researcher
Websense Security Labs
http://www.WebsenseSecurityLabs.com
--


-Original Message-
From: kevin montuori [mailto:montu...@gmail.com] 
Sent: Friday, October 09, 2009 1:19 PM
To: The elegant MVC web framework
Subject: [Catalyst] Re: Deployment in practice

> "MA" == Mesdaq, Ali  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/


 Protected by Websense Hosted Email Security -- www.websense.com 

___
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

2009-10-09 Thread Devin Austin 
On Fri, Oct 9, 2009 at 3:08 PM, J. Shirley  wrote:

> On Fri, Oct 9, 2009 at 1:18 PM, kevin montuori  wrote:
>
>> > "MA" == Mesdaq, Ali  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

2009-10-09 Thread J. Shirley 
On Fri, Oct 9, 2009 at 1:18 PM, kevin montuori  wrote:

> > "MA" == Mesdaq, Ali  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/

[Catalyst] Re: Deployment in practice

2009-10-09 Thread kevin montuori 
> "MA" == Mesdaq, Ali  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] Deployment in practice

2009-10-09 Thread Mesdaq, Ali 
I will second this recommendation or something similar to this. It’s a lot 
easier when you have two branches that serve very specific purposes. One branch 
is production code and that can be sync’d every few minutes with whatever 
source control system and with a script similar to the one J Shirley posted a 
link to the webserver can sync to this code with 100% confidence. The other 
branch for development is where you check in daily changes. This is the branch 
you manually have your staging machines sync with. Once it passes the tests the 
code can be merged into the production branch and will auto deploy. The 
advantage is you will also have a much easier process in trouble shooting 
production issues because the changes on the files will be much less so it’s 
easier to find sources of new issues. Some people like to manually update from 
production code branches which is the safer way to go but at the very least 
make sure you have the two separate branches. If your checking things into 
production to fix typos or similar then you’re not using production branch 
approach properly.

Thanks,
--
Ali Mesdaq (CISSP, GIAC-GREM)
Sr. Security Researcher
Websense Security Labs
http://www.WebsenseSecurityLabs.com
--

From: J. Shirley [mailto:jshir...@gmail.com]
Sent: Friday, October 09, 2009 9:12 AM
To: The elegant MVC web framework
Subject: Re: [Catalyst] Deployment in practice

On Fri, Oct 9, 2009 at 7:55 AM, Tobias Kremer 
mailto:tobias.kre...@gmail.com>> wrote:
2009/10/9 Octavian Râşniţă mailto: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


Click here to report 
this email as spam.


 Protected by Websense Hosted Email Security -- www.websense.com 
___
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

2009-10-09 Thread pro...@gmail.com 
On Thu, Oct 8, 2009 at 11:04 PM, Devin Austin wrote:

>
>
> On Thu, Oct 8, 2009 at 9:01 PM, 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.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/

Re: [Catalyst] Deployment in practice

2009-10-09 Thread John Goulah 
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?
> 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] Deployment in practice

2009-10-09 Thread Octavian Râşniţă 

From: "J. Shirley" 

On Fri, Oct 9, 2009 at 7:55 AM, Tobias Kremer 
wrote:



2009/10/9 Octavian Râşniţă :
> 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-09 Thread J. Shirley 
On Fri, Oct 9, 2009 at 7:55 AM, Tobias Kremer wrote:

> 2009/10/9 Octavian Râşniţă :
> > 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

2009-10-09 Thread Tobias Kremer 
2009/10/9 Octavian Râşniţă :
> 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/

[Catalyst] Deployment in practice

2009-10-09 Thread 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?

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/