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.
Related
So - let's say I develop a PHP app which I develop in a vagrant box identical to production envrionment. So - as an end result I would have a *.tar.zip file with a code...
How would one organize a deployment into production environment where there are a lot of application servers? I mean - I'm confused how to push code into production synchronously all at once?
More information:
on server code is stored like this:
project
+current_revision ->link to revisions/v[n]
+revisions
+v1
+v2
+v3
...
+data
So when I have to deploy changes I usually run a deploy script that uploads updated tar onto server with ssh, untars into specific dir under revisions, symlinks it into current_revision and restart php-fpm.... This way I can rollback anytime just by symlinking to an older revision.
with multipe servers what bothers me is that not all boxes will be updated at once, ie. technically some glitches might be possible.
If you're looking for a "ready-to-go" answer, you'll need to provide some more info about your setup. For example, if you plan to use git for VCS, you could write a simple shell script that pulls the latest commit and rsyncs with the server(s). Or if you're building on top of Symfony, capifony is a great tool. If your using AWS, there's a provider plugin written by the author of Vagrant that's super easy to use, and you can specify a regex for which machines to bring up or provision.
If instead you're looking for more of a "roadmap", then the considerations that you'll want to take are:
Make building of identical boxes in the remote and local environments as easy as possible, and try to make sure that your provisioning emphasizes idempotence.
Consider your versioning/release structure; what resources will rarely or never change? Include those in a setup function instead of a deploy function, and don't include them in your sync run.
Separate your development and system administration concerns; i.e. do not just package a vagrant box with a *.tar.gz and tie it through config.vm.box_url. The reason for this is that you'd have to repackage every production server with a new box every time you deploy, instead of just changing files on the server, or adding/removing some packages from the server.
Check out some config management tools like Chef and Puppet; even if you don't end up using them, they'll give you an idea of how sysadmin professionals approach this problem.
Lots of ways. If starting from barebones (no cloud infrastructure), I'm a fan of the SVN branch hook. Have a SVN repo for your code. Set up a post-commit hook on it, which checks if anything in /branch/production/ has been changed.
If it has, let the post-commit hook fire all your automated roll-out procedure - and in this case, an easy way to do so is to let all your servers known* to svn export the branch. As simple as that!
(* that's the hard step)
I have been told that SVN is a good method of being able to manage multiple sites running from the same code base. I am struggling however to find out enough information about SVN and how it would be used in this way. Basically, I would look to put my ecommerce system into an SVN and then run it on multiple sites, each having specific configuration settings in order to specify allowed modules.
Could anyone advise me if
(a) SVN is the correct method to do this
(b) There is any material/tutorials out there on how best to do this.
SVN is a versioning tool, not a multi-site management tool. Although I can see how it can be used in that way, that is not what you get out of the box. You need an understanding of SVN first.
As an example, each website could have it's own svn branch of the code. Any updates that you want to propagate to the rest of the branches, you would merge with trunk, then update the rest of the branches.
That said, branching can very quickly get very complicated, especially with multiple developers. Git handles branching much better than SVN (my opinion). Git is also a versioning tool, just like SVN. But again, it's designed for versioning, bit multi-site management.
I suppose that you could treat each installation as a working copy of the SVN repository, log in to each system, and do a checkout from the latest code on the SVN server.
I do not recommend this approach. It will be slow and will pollute your application folders with a bunch of svn data that you do not need on your web server. You do not want to risk by putting it insider your web root.
I recommend using rsync. With rsync, pushing out updates is slightly more complicated than copying a local file. If you are running linux, the odds are that rsync is already on your system. On windows you can run it under cygwin or find various alternative implementations, such as DeltaCopy.
If for some reason you can't use rsync won't work, I would recommend SFTP.
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.
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.
I have what I believe is a tricky situation but this usually indicates I'm ignorant of something quite simple.
I currently have one php project that is in an svn repo, call it 'firstproject'. The working copy of this is an apache virtual host dir so I can happily run this project at any point of development through a browser.
I now have another project 'newproject' that I want to use some of the core code of 'firstproject' but when newproject requires me to refactor parts of the firstproject classes I would like for that to be integrated back into firstproject at some point.
Is there any way to set svn up so I can have a working copy of newproject happily in it's own apache virtual host and comprising some code from firstproject and then its own code and for svn to keep tabs on which is which or is it a case of creating a 'newproject' branch of firstproject, editing away adding the newproject code and then doing some sort of merging of code back into 'firstproject' when it seems appropriate?
Many thanks to anyone who can help me thinking about this, it feels like there should be a neat way but maybe there isn't.
It seems to me that firstproject should release some deliverable (a library). newproject can then consume this.
If that library needs to change, then the changes should be made in firstproject, and released.
That's how I'd normally manage this sort of dependency in a non-PHP world. I'm not sure that in PHP it should/would be any different. It's a bit of a headache, but you're building a reusable library that a downstream project can consume (and choose which version it consumes, note).
If there is a large part of the code that is common, then you can consider using a common repository instead of two seperate repositories for these two projects. You can then take out a branch for the code that might change within the project newproject . The workspace on the newproject apache server will have to be from this branch so that any changes can be committed back to the branch and merged back to the trunk when you are ready. This way you can incorporate the changes back to the firstproject mainline/trunk.
You can also explore svn externals for another approach to mix and match if you need a workspace with checkouts from multiple repositories. I have not implemented this myself but you may find the details here:
http://svnbook.red-bean.com/en/1.1/ch07s04.html