My team currently has a development web/database server and a live deployment web server and a live database server. We use SVN with the repository stored on the development server but the problem is our deployment process.
Currently when we need to deploy an update to the live application we simply use SFTP to transfer from the repository to the live web server and then amend the database on the live server to reflect the development database. This is a really slow process as we also minify all javascript and CSS files.
I have used Capistrano for Ruby and Cruise Control for java but I have never used anything for PHP. I'd rather not have to build our own if something already existed. Does anyone know of anything?
Check out my recent bounty question:
Setting up a deployment / build / CI cycle for PHP projects
I got a number of very good product recommendations. There's also a Cruise Control connector for PHP, phpUnderControl.
I did a great job with auto deployment using CruiseControl and phpUnderControl
http://topecoders.blogspot.com/2010/04/how-to-install-cruisecontrol.html
They work pretty cool with all tests and code analysis being done automatically. It also deploys projects on every successful build.
Related
Recently I investigated the continuous integration development process, so I installed a TeamCity server, set up the build and tried to make it automatically deploy the build artifacts (my web app) to the web hosting server through FTP. However, I failed on the last step (deployment) because of thousands php files deploying for a very long time. So, I'm wondering if there is a way to do it more quickly, perhaps using zip-archives or something else.
So, my question is, if there is a common way to solve such problem?
Use git for deploy. It get only changes
Example using hooks: gist.github.com/noelboss/3fe13927025b89757f8fb12e9066f2fa – Łukasz Gawrylu
Recently I have created a PHP/MYSQL based website, site is going to be live in next few weeks, my mentor asked me to setup a dev site and a live site, make changes & testing for new features on dev and then upload them to live.
I can do that but that seems a hard process because I'll make changes here and will upload them manually to live server. There are chances that I'll miss some files or dependencies, while uploading.
I thought to have a SVN kind of facility which will manage the dev and live server synchronization. In case I'll miss any files it will highlight me that this file is not yet synchronized on live etc. Also it will maintain the versions of my live and dev site on daily basis, in case anything goes wrong, we can get the earlier versions.
I am not fully aware with what is SVN, how to setup it and how to use it. Could you guys, please guide me how to setup it and how to use it. Which SVN software will be good.
My Server configs are: its a LAMP facility (Ubuntu)
I am using Windows as a local system to make changes (dreamwaver cs5) and upload them to FTP.
Thanks.
I have a similar configuration to manage dev, staging and deploy for many clients. We still use SVN because it's largerly supported natively and it's also integrated on simple developer tools such as CODA (we're also working with GIT but we plan to move the web app deployment on GIT as soon as it will be integrated in that kind of editors).
On the client side (developers side) you can use any SVN visual client like Versions (OSX).
On the server side, we developed a custom php application to take control of each working copy on the server and run new updates SVNDeploy otherwise you can just ssh on the server and run your custom update.
If you will follow the SVN suggested repositoy structure
/tags
/trunk
/branches
You can easly manage your deployment in this way:
Current release in the /trunk folder
Development snapshots under /branches (like /branches/2.0-dev etc.)
Old released versions under /tags (like /tags/1.0, /tags/1.5 etc.)
We used that configuration in the last 3 years with 5 servers and around 25 developers and it worked fine since now.
Some useful links to configure your own subversion server:
http://svn-ref.assembla.com/subversion-server-guide-mac-os.html
http://aymanh.com/subversion-a-quick-tutorial
Take a look at Mercurial.
There are several videos on YouTube that you can watch to get a feeling for what Mercurial is all about. (Start here.)
I have a question related to phing. Do I use it on my local development machine to deploy an application or do I call it via ssh from production machine? I'm not sure where to do the steps from Eran Galperin (What is your preferred PHP deployment strategy). I'm a beginner with deployment scripts. So be forgiving :)
Marco
You'll usually have two deploy scripts - One that you run locally, which ssh's in to the remote server and then kicks off the remote script.
Your local script might do an svn export, zip the contents and push them (scp) to the remote server first. The remote script would do stuff like migrating, restarting services etc.
The basic strategy is that you create a build (well, basically a copy of your web application that you can put online) on your local machine, and then deploy it on the server.
You run it on your local machine and the PHPing will connect to production server and deploy the website. :)
Phing can be applied in many ways.
If you don't have directives on how to deploy, the best way is usually first to generate a "test build" from your local copy, check out if it is working as intended and then generate the productive build.
In some cases where you have to follow certain rules in your development enviroment you can easily adapt Phing to meet those demands.
I developed a phing deploy script and I've used it in both of the ways you've described. As long as the phing library and dependencies are installed locally or on the remote machine you can do it in both ways, and it's actually a benefit to be able to run it from any of your environments.
Let me elaborate on my experience, but keep in mind that every person lives within the microcosm of the needs and requirements of their own projects/studios so it's possible that what works for me, may not work for other people.
I think deployment is usually so important for a business that it needs to happen in the exact same way every time. When there's a multitude of people doing the deployments, then it's easy for bad habits or procedures to diverge and that's when mistakes can happen. Automated deployments with phng are handy because if everyone is using the same procedure, then there's much lower potential for mistakes. Phing makes it easy to follow strict procedures because all the developers have to do is to run a simple command like "phing deploy" or "phing build" or what have you.
Now going back to your original question, it's also helpful for these procedures to be adhered to on local development machines as well as on staging, testing, production servers because just like people, machines can have small ideosyncracies that differ from machine to machine. With phing, you can develop a script that will have the same results on any of your enterprise machines (depending on the strength and intent of your code but phing lives in a format that makes it easy to meet that ideal). So if you run your phing build from your development box, ideally it has the same effect if you run it from your testing box or your production server. If you can run the deployment the same way on any machine, you can feel confident that any problems that arise after deployment were not a result of your deploy procedures (as they will not differ from when you deployed to your testing or local dev box).
It's really nice to be able to deploy my code to my local machine with the exact same procedure that I use to deploy it to production.
As far as what is the best to do, I say, why not all of the above? If you can run it locally, then you can run it remotely. If the deploy procedures are strong, then the result will be the same.
You can do it both ways. You can run the tool locally as you develop to run tests and just generally ensure that your code is in good condition. The server automation (if you choose to do that) can also run tests, generate documentation, and deploy changes to test or production setups.
Doing it locally reduces the chance that the process will get stalled on the server setup, while the CI works on a regular basis to ensure nothing has been broken via mistake.
I've inherited a significantly sized internal app at the company I work for. It has two parts. One runs on a LAMP server, the other runs on a WAMP server. There is no source control to be seen.
Currently, developers will log into each server via FTP and just directly edit the PHP files that are there. Or log into phpMyAdmin and make changes to DB schema where necessary.
What is the best way to implement some source control into this situation? I'm not very knowledgeable on how to best setup CVS ans SVN. Would all developers need their own "test system"? Meaning, would I have to setup a LAMP+WAMP enviornment for each developer? Or can they would off a central dev server? What is the best way to deploy changes that have been made?
Developers all use Windows. We also use Zend Studio 5.5 for development.
Thank you in advance for any advice.
It's really not a lot of effort for a developer to have a personal LAMP/WAMP running locally or in a VM. A local dev server is worth having for testing non-live changes in a closely matched environment but it doesn't really scale if all developers are making their changes on that at once.
I'd have all developers committing to trunk in Subversion and then have a stable branch which is automatically (using a post-commit hook) deployed onto the server. Only certain people should have write access to the stable branch to ensure a junior developer doesn't accidentally screw the live server.
That's a horrible way to work on websites, especially with a team. The whole setup should be changed.
The source code should live somewhere else, and then get deployed to the website when it's ready. You could have a script that does the deployment and whatnot (copy the files over ssh, plus any other setup if needed, etc). The point is: no one should ever edit files directly on the production server.
I've read a number of topics in the same sort of ballpark as this one, but in all honesty I'm still not exactly sure on the best approach (as a starting point). I am a solo developer in a small office and I have around 30 websites which are hosted on a linux VPS. I want to start using using version control (probably SVN) and also set up a staging server. At the moment, I do development either locally on my machine before using FTP to upload to the live server, or ocassionally for small changes I edit the remote files directly, which is not an ideal approach.
I'm looking for some guidance on how to improve my development environment. I imagine I should be installing SVN on the web server, which would then allow me to check out versions to my local machine (which would also require SVN i think). Also, if I want to set up a staging server, should I just set up subdomains for each of the live websites, then use these subdomains for showing clients changes to the site before making them live?
Hope this makes sense!
This is what we do at work:
We have a staging server running Apache and a Subversion server. We have a post commit hook that updates a working copy in the htdocs directory, that way, when a developer commits something it automatically gets updated on the staging server, so everyone can see the latest code.
On the client's production servers (the ones we can control) we have the Subversion client installed and the website is a working copy. When we need to update the live site we login to a shell and run svn up. If you do something like this, make sure to limit access to the .svn directories, either with .htaccess files or from the main Apache config.
We have a custom app that manages the projects, but that is only because we're lazy and don't want to setup each project by hand, the app creates the necessary directories and working copies. You could write a quick script to do this.
We never, ever, edit files via FTP on the live site. All in all we have been using this setup for almost 2 years and aside from the occasional conflict on the staging server, we never have had any problems.
You can actually install the SVN server on your local machine, which I would recommend in lieu of installing it on the web server (assuming you make backups). The easiest thing to do, since it’s only you using it, would be to use the file:// protocol, but using svnserve is a little more robust, and the preferred method if you want to take the time to do it.
#Michael, I disagree - I would say it's better to install on the linux vps, especially if you are already paying for the hosting service. I find it very helpful to be able to browse and download stuff from my svn repo wherever I am, from whatever computer I'm on.
#nicky, I started with svn (and version control) several years ago and I took baby steps which made it easier to tackle.
If I had to do it over again, I'd read the svn book to start with. The book is very well laid out and didn't take more than 1-2 days to plow thru.
While you're reading, install svn on your linux vps with an apache front end.
Once you have that up, pick one of your websites and import it into svn. This is how I structure my svn repo. For example, say my repo is hosted at http://mysvn.mydomain.com/svn/:
mywebsite1
- trunk
- tags
- branches
mywebsite2
- trunk
- tags
- branches
Don't worry about creating the perfect structure. It's pretty easy to re-organize especially when you're starting out. After you import a few projects into svn, you'll start to get a feel for which projects should have their own "trunk/tags/branches" dir structure and which can be combined.
For creating test environments, I do exactly what you describe. I use build scripts to checkout from svn and download files into dirs that are mapped to subdomains like "test.clientsite.com" (I work primarily in java and use ant and maven, but I think you can use whatever scripting language you're familiar with).
Once you get used to version control, you'll never go back, good luck!