Deploying PHAR vs. PHP source

[Jason Edgecombe]

Hi everyone,

I'm looking for some guidance about best practices regarding deploying
PHP applications to production. Currently, my team manages multiple PHP
applications. The team includes student interns, and a full-time web
developer. I'm a Linux admin that is supporting the web team and writing
the PHP backend for our account provisioning system. Our full-time web
developer is writing the PHP front-end.

Background:
Currently, all web our applications are deployed to staging or
production areas using "git push" to sync the git clones in those areas.
We don't have a an automated deployment pipeline at this time. Our
developers have direct write access to the testing and production file
areas. The git clones are parents of each other in a tree-like
arrangement. [developer (multiple) -> test (single) -> prod (single)]

The entire team, including me, is accustomed to the "folders of PHP
files" application model. A PHAR file is a PHP archive and is analogous
to a JAR file for Java.

The project will use PHP as a general purpose shell language because it
needs a MySQL DB and PHP is the most understood language among the team
of people who might potentially maintain the code.

The code is being ported from Oracle+Perl to PHP+MySQL to reduce the
number of DB products, and PHP is more widely known among the team than
Perl.

The question:
I'm debating about using PHP's PHAR files to deploy and manage the new
account provisioning system. My weak understanding of Continuous
Deployment practices says that the PHAR file should be used to keep
things immutable and compact, but I doubt that the rest of the team will
accept this strategy. The PHAR format would prevent modifying stuff by
hand in production, which happens frequently, but I don't like the
opaque artifacts that are difficult to tell from which version of the
source they were generated. I don't want to end up being the only person
who can support this application, again.

Thanks,
Jason

[Mark Goldfinch]

Hi Jason,

On 1 September 2014 08:49, Jason Edgecombe <ja...@rampaginggeek.com> wrote:

I'm debating about using PHP's PHAR files to deploy and manage the new account provisioning system. My weak understanding of Continuous Deployment practices says that the PHAR file should be used to keep things immutable and compact, but I doubt that the rest of the team will accept this strategy. The PHAR format would prevent modifying stuff by hand in production, which happens frequently, but I don't like the opaque artifacts that are difficult to tell from which version of the source they were generated. I don't want to end up being the only person who can support this application, again.

Couldn't comment on PHAR and good/bad that is, but we do have a production PHP application which we have a CD pipeline for.

We're using the combo of Stash + Bamboo + fpm + mcollective + Puppet as our Repository, CD server, packaging, orchestration and Config management respectively.

Overall the pattern we're looking at is using is:  Libraries are included as dependencies within our OS-package generated by fpm, whereas dependant services are managed by puppet.

There is a fair amount of work to get everything to function, but having auto-deploy to test and push-button deployments to production are proving very useful for the team as a whole.

We've definitely borrowed a lot from Jez Humble and David Farley's CD book, if you haven't already I'd strongly recommend picking up a copy.

Hope this is of some help..

Thanks,

-- 

Mark Goldfinch
Platform Manager, Modica Group

Tel: +64 4 498 6000

mark.go...@modicagroup.com

www.modicagroup.com

      

Trusted Customer Engagement - communicate, connect and transact with your audience via mobile and internet channels

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.

[gareth rushgrove]

So, while a single deployable artefact is generally a good thing
(whether Jar, PHAR, deb, rpm, what-have-you) it might not be the best
thing to start with in your case.

You say "The PHAR format would prevent modifying stuff by hand in
production, which happens frequently"

The idea of modifying things by hand is the first thing you need to
kill in my experience.

Make the deployment repeatable and automated. The simplest
manifestation of this is just a simple script. The only way code is
deployed is via that script. No exceptions.

I think until you do that and everyone buys in then you won't
necessarily solve your broader deployment problems. One you have that
in place then things like a single place to deploy, immutable
artefacts, etc. start to become useful, and you can introduce them to
solve genuine problems that the entire team can buy into.

Gareth



> Thanks,
> Jason
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "devops" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to devops+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Gareth Rushgrove
Web Geek

morethanseven.net
garethrushgrove.com

[Jason Edgecombe]

Thanks Mark. I'm using fpm for our pxeboot files deployment, but RPM's
won't work very well unless we move our web apps off of a shared file
system. I'll keep the webapp-as-rpm idea in mind for the future.

Jason

[Jason Edgecombe]

A simple script to deploy sounds good. I want all of the devops
goodness, but I'll just have to take it slowly.

Jason

[Mark Goldfinch]

On 2 September 2014 08:48, Jason Edgecombe <ja...@rampaginggeek.com> wrote:

A simple script to deploy sounds good. I want all of the devops goodness, but I'll just have to take it slowly.

From our experience, I can say it has been an incremental journey for us.  Real-life dictates there's other work to get done.  As long as you have continued progress, eventually you'll look back and wonder how you ever managed previously :-)

[Jason Edgecombe]

On 09/01/2014 05:14 PM, Mark Goldfinch wrote:
> On 2 September 2014 08:48, Jason Edgecombe <ja...@rampaginggeek.com> wrote:
>
>> A simple script to deploy sounds good. I want all of the devops goodness,
>> but I'll just have to take it slowly.
>
> >From our experience, I can say it has been an incremental journey for us.
> Real-life dictates there's other work to get done. As long as you have
> continued progress, eventually you'll look back and wonder how you ever
> managed previously :-)
>

Thanks. Good to know.

BTW, I bought the Continuous Deployment book last week, and I'm on
chapter 2.