this is a question on PHP mainly. I was wondering: How do you make sure that all necessary libaries are packaged with your application when you do a deployment to (production) servers?
A more concrete example: I have an app running on Zend Framework and each time I roll the application to a server the deployment process creates a fresh "installation" on that system. Therefore, I need to bundle Zend Framework together with my application and then copy the files to the right places together (it is done automatically). Currently, I am using a svn:externals definition to get the files out of Zend's SVN system during deployment, however, I don't want to rely on that SVN and I also don't want to put traffic on external SVNs with each deployment.
In the Java world, I am used to Maven which handles such stuff using central artifact repositries. I know that there is a Maven4PHP version, however, I am more looking for a PHP-based solution. Additionally, I don't believe that PEAR is a good way to go as it doesn't really fulfill my requirement of bundling the applicaiton (incl. libs) into a single deployable.
Is there some tool available already that I am not aware? Or do you have any great technique that I should know?
Thanks much for your help!
Michael
There's a build system called Phing which is written in PHP and based on Apache Ant.
I personally can very well live with externals.
I think the vendor branching would solve the problem from your example quite straightforward, but if you also don't like large repositories I'd recommended to keep watching on the modern toys like composer and what it solve(and maybe phark, I never heard before :) )
It isn't production ready yet but you might want to keep an eye on the Phark project. It is a port of Bundler to PHP.
While looking through the Simplify your external dependency management slides I came across a tool called pantr which can be used as a PEAR installer. pantr as PEAR installer which allows you to specify your dependencies in a project specific file.
The article Version Control != Dependency Management has some information about using the new PEAR installer called Pyrus
Related
It seems the standard way to deploy with Rocketeer is to do a pull deploy, that is, it will do a git clone from the server you are deploying to. What I want to do is push a set of files after having done a build on a CI server to the server being deployed to.
The reason I want to do this is that usually my projects have lots of extra stuff not required for production. I usually like to construct a build folder and run a build script that packages a final product. I want to use Rocketeer to push the results to staging/production servers. It was suggested in this article it can be done: Deploying PHP Applications with Rocketeer and Docker
However, after reading the rocketeer documentation there is nothing that speaks to that strategy and its seems a bit against the grain to try. I'm open to ideas given my problem.
As the author of the article, I owe you a clarification. I mentioned those two types of deployment paradigms in a general sense just to introduce the different concepts. As I am aware of, Rocketeer supports only "pull" deployments. Sorry for the confusion!
For deploying the generated files to your server from a CI, I think the most straightforward way is to usea tool like scp, rsync or just download it from S3 if you're storing your built package in a bucket.
I'd like to ask about real life experiences with release management of PHP projects over Hudson CI server.
Our projects are separated into subprojects: frontends, framework, libraries. Everything is stored in our SVN as project of its own. Different frontends may depend on different versions of framework which itself depends on different versions of libraries.
So far we do release management by hand. We have one environment serving as test and production to avoid environment differences problems releasing the project. We tag each subproject in SVN with release number and checkout everything for testing accessible under test domain. Once we do testing and fix the bugs we tag new versions of everything in SVN as production and relink production domain to point to the new code. This manual process has its obvious problems and there is no way we are keeping it.
Under my research to move to automated solution I already installed Hudson and configured it for PHP projects (Phing, ppUnit, etc...) I am familiar with writing build scripts under Phing or Ant. I red all possible "the basics" stuff of setting up CI environment and preparing project and done that. What I did not find is an example of release management similar to what we do manually taking into account all the dependencies we have. Can you please point me out into a right direction?
I'm afraid there is no such complex thing readily available. We had to solve quite similar problem and we ended up using very similar configuration you were planning to use (or already using).
We have multiple application cores and then specific client modifications on top of that. All is stored in SVN. Additionally we use svn:externals to link Framework and other 3rd party libraries with the application.
All is done using Phing and although it took us some time, Phing helped a lot and I can really recommend it.
Client specific addons are fetched automatically using phing. Everything is configurable through build properties.
For database schema updates we are very happy with dbdeploy which is a part of Phing. Although we had to modify it slightly for our needs.
Additionally we added a support for creating pre-configured self-extracting Linux installer so the whole complicated process of creating a deployable package consists of calling one phing target and passing a correct build property file. To create those installers we use this simple technique (http://www.linuxjournal.com/node/1005818).
Again using Phing the created package is automatically uploaded to a target server, executed over SSH to do the deploy.
Then we use Hudson for automatically creating installer packages (in addition to automatically running phpunit tests and Selenium/Hmres tests) and storing them in a defined location/or as artifacts. Our support team can then grab the packages and do the production deployment themselves (our QA/Test environments are updated automatically by Hudson).
Additionally the code is automatically encoded and licensed using ZendGuard where necessary.
The brief description above is just to illustrate what can be achieved using Hudson, Phing, SVN and PHP. Full technical details would obviously be too long for this post but I would be happy to elaborate more somewhere else.
does anyone know a package manager library for PHP (as e.g. apt or yum for linux distros) apart from PEAR? I'm working on a system which should include a package management system for module management. I managed to get a working solution using PEAR, but using the PEAR client for anything else than managing a PEAR installation is not really the optimal solution as it's not designed for that. I would have to modify/extend it (e.g. to implement actions on installation/upgrade or to move PEAR specific files like lockfiles away from the system root) and especially the CLI client code is quite messy and PHP4. So maybe someone has some suggestions
for an alternative PEAR client library which is easy to use and extend (the server side has some nice implementations like Pirum and pearhub)
for completely different package management systems written in PHP (ideally including dependency tracking and different channels)
for some general ideas how to implement such a PM system (yes, I'm still tinkering with the idea of implementing such a system from scratch)
I know that big systems like Magento and symfony use PEAR for their PM. Magento uses a hacked version of the original PEAR client (which I'd like to avoid), symfony's implementation seems quite integrated with the framework, but would be a good starting point to at least write the client from scratch. Anyway, if anybody has suggestions: please :)
There is Composer also.
Have you checked Maven for PHP? I've only used Maven in the context of Java applications, but it's certainly:
Easy to extend – it's really easy to implement Maven plugins
Manages dependencies – distinguishing compile, test and runtime dependencies (though the compile/runtime distintion doesn't make sense in PHP).
Repositories are trivial to put up – Apache with mod_dav will give you a working writable repository, but you also have Nexus.
Distinguishes snapshot from stable artifacts; allows several policies for when to check for new snapshot artifacts and from which repositories get each type.
And many – many – more things.
PEAR2/Pyrus was built for package management for arbitrary applications. I believe it was modeled after the apt/yum architectures.
Helgi - core PEAR member - covers some of it here - http://www.slideshare.net/helgith/pear2-pyrus-the-look-ahead but the documentation is pretty solid too: http://pear.php.net/manual/en/pyrus.extending.installation.php
I'm deveoping a big project, I have the dev folder (connected to a specific subdomain) then the "real" folder, the live one. When I'm ready to push patches or whole new versions I'm currently copying the files individually, is there a program that can help me do this task?
Keep in mind that some files (the config one and the htacess) and folders (the dev ones) do not need to be copied in the live version.
Thank you
Yes: subversion (or any other version control system) will allow you to push changes painlessly.
A simplicistic solution would be to have one checkout where you develop and you commit to, and another checkout which is the deployment. When you are ready, you go to the deployment directory, and do a svn up, to sync it. It won't overwrite modified or excluded files.
There are build packages like Capistrano and Phing which can help with more complicated deployments. Capistrano is Ruby-based, so it is a more natual choice for RoR applications, and Phing (being PHP-based) can be a little more convenient for PHP-based projects. In my experience, Phing seems less mature than Capistrano, but is a little more flexible because it doesn't assume you are working with a Ruby project like Capistrano seems to do. That's entirely opinion of course.
Both tend to take more thought and work to configure up front, but once you've designed the deploy script, you can run a single command and have everything happen for you while you watch. Both tools can integrate with source control like SVN, and bring copies of your project out of the repository for you. You can also break your deployment out into sub-parts, like a traditional Makefile, which helps with testing and reuse. If you want the process you go through for your releases to be bulletproof and consistent, you need to use a tool that will manage all the steps involved for you so you remove the human-error component.
What would be a good tool-for-the-job to do automated deployments of LAMP-based applications(MySQL, PHP, Zend Framework) to integration and staging environments?
I am looking specifically for tools that handle deployes to remote hosts. I assume building tools such as phing and ant I assume could be used for that, but I was wondering if there is something better for this case.
For integration, especially for continuous integration, I like phpUnderControl (which is a tool for PHP projects, but is itself based on CruiseControl, which is quite know in the JAVA World) : it deals with :
fetching the last revision from SVN
launching the automated tests (PHPUnit)
php_CodeSniffer
Generation of the PHP Documentation (phpDocumentor)
and provides a nice interface for users to see the results of each build.
And, to begin, here's an article that explains how to set phpUnderControl up : Getting started with phpUnderControl
(Each time I, or some colleagues, have installed phpuc, we did almost as explained in that article, from what I remember)
For staging, I generally go with a couple of phing tasks to build a tar.gz archive, that I deploy to the staging server once in a while, using another phing task to un-tar the archive, and create the required symlinks (or stuff like that).
The idea being that Continuous Integration happens all the time, and has to be fully automatic, while deploying to staging is done only one in a while (once per week, for instance), and can be done semi-automatically.
Configure a build server, something like CruiseControl is excellent for this and roll your own custom Nant scripts if needed or use Exec tasks to take care of the deployment.
For these things like specific deployments each with their configuration issues and intricacies, there is hardly ever something out-of-the-box.
Look at it this way, rolling your own scripts and batch files definitely means you know all about the steps and can configure and modify it anyway you like, rather than some magic fairy dust going on, and when things break - having no idea where to fix it.