Maybe I'm benefiting from a platform of only 40 servers, tho I'm not sure what our limits would be.

For us they're simple (virtual) web servers.

If one plays up, drop it, rebuild, and away we go, I kinda got that from Yahoo! Don't worry about what went wrong, just rebuild and carry on.

This is all a brand new (2 years old) Catalyst env, so yes, I've had some benefits.

Our ~/perl5 is in svn too, so live and dev boxes should always carry the same code.

Would you deploy anything without ensuring the perl5 is also fully up-to-date first? That's our first check with our own deployment script?

We're only a team of 3, so all dev's are also dev-ops so to speak.






On 13/05/15 22:26, James Leu wrote:
Excellent idea Robert.  I've been doing it this way
for so long, it would be nice to take fresh view at
how others are doing it.


For us RPM add two benifits:
- It allows us to validate that files have not changed from
the originial reployed version.

- I can give our Ops team a RPM and have them schedule/handle
deployment

I can see doing something similar in a docker environment
but I have had not had time to vett that idea.

On Wed, May 13, 2015 at 10:08:17PM +0100, Robert Brown wrote:
One of my previous employers deployed with RPMs.

And I never understood why.

It's a good question for the community here, what's your
deployment strategy, and why is it so?

What would you change if you're not the decision -maker.




On 13/05/15 21:58, James Leu wrote:
Just to add to Robert's idea.

We use perlbrew and Carton for our catalyst environments
We deploy via RPMs, but each RPM contains a perlprew environment
and a local lib dir managed by Carton.

On Wed, May 13, 2015 at 06:26:40PM +0100, Robert Brown wrote:
Not to answer your actual question, but...

Have you also thought using Perlbrew http://perlbrew.pl

As regular user, you can install any version of Perl locally (to
your home dir), plus all the modules via cpanm, and keep
everything self-contained for a particular user.

It's made our deployments a breeze, rather than dealing with the
system-wide perl, etc.

(There's also local::lib tho I've not delved into that myself).

Hope it helps a little.

Rob


On 13/05/15 18:16, Duncan Garland wrote:
Hi,

I've just spun up a Rackspace server with Ubuntu 14.04 and
tried to install Catalyst from CPAN.

If the print out means what it seems to mean, then Catalyst
will no longer install cleanly from CPAN on any version prior
to 5.20.

It's saying that there is a dependency on Tie::StdHash and
that Tie::StdHash won't install without force because the
latest version of the module is part of perl-5.20.2.

It won't effect me because I'll just force it or download an
older version of the module.

All the same, it seems a bit poor.

Is it deliberate?

Regards

Duncan



The information contained in this message is for the intended
addressee only and may contain confidential and/or privileged
information. If you are not the intended addressee, please
delete this message and notify the sender; do not copy or
distribute this message or disclose its contents to anyone.
Any views or opinions expressed in this message are those of
the author and do not necessarily represent those of
Motortrak Limited or of any of its associated companies. No
reliance may be placed on this message without written
confirmation from an authorised representative of the
company.

Registered in England 3098391 V.A.T. Registered No. 667463890


_______________________________________________
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/



_______________________________________________
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/

Reply via email to