I use Git to track local changes in my PHP web applications, and I was wondering if it would be a good idea to use Git on the server as well, so that I could just use git push to deploy my changes. Would there be any pitfalls with this approach?
This seems like a nice way to do things. If you're tagging and branching properly it will enable you to quickly switch back to working versions of your site too in the event that something breaks.
I think this is a fine way to do it. I handle things in a similar manner, where live sites are just a checkout from the repository, and i update them as necessary.
Git is fine but you can do a lot better then just using git pull. Take a look at railess deploy for capistrano.
Capistrano basically does a combination of rsync and git pull to deploy copies of your website. It supports roleback, staging and distributed deployments.
And online hotfixes can be pushed back to development.
Being able to do a git status on a live system can be a live saver.
Go for it!
Caveats
Make sure the the ".git" folder isn't accessible from the web.
With PHP the source code is usually present on the webserver, so that doesn't add additional risk in case the server is hacked.
I would be in favor of using a technique like this if only because you can be sure anything on your deployed site is also being tracked in git. That is, it encourages a best practice and discourages ad hoc changes that aren't under source control.
For another alternative, check out this article about how Twitter uses BitTorrent to manage deployment: http://torrentfreak.com/twitter-uses-bittorrent-for-server-deployment-100210/
It's probably most useful when you need to deploy quickly across a large collection of servers.
I think its a great solution. I have been using it to deploy my website for a long time... Its nice because you can almost instantly push your changes into production just by updating the folder. I have encountered no security issues or anything with it.
Enjoy!
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.
Good day to you all,
I am currently developing a project on Laravel. So far I have always developed online, directly editing my files on the webserver throuh FTP (using PSPad or similar simple editing tools).
What I want to do now (and what i believe most people actually do) is setup a (W)LAMP stack on my local machine and program locally. However it is a little bit unclear to me how to keep my local code (including databases) in sync with the live website. How do you folks do that? I know there's probably lots of ways and tools to do that, but what would be your advice for a best practice? Any advice would be very welcome :)
What many companies do is build offline, then push their edits up to a server using git.
Im no expert on the software so ill describe what you do in a basic form:
My advice would be to create an online repo (repository) to store your project while you edit/update.
There are several git project management systems such as github or bitbucket. I personally use bitbucket
What git does, is when you have built or added what you need offline on local (w)lamp, you then git push them up to your repo or server. The changed files then get merged with the existing on the repo or the server. If you'd like the most recent version of your project you'd simply just git pull them down.
Read the full documentation here to see the wide range of options available when using git
We have a settings array within our platform available as $res::Config.
At runtime, a variable is changed from 'dev' to 'live' after checking the HTTP Host, obviously depending on the IP address.
Within our framework bootstrapping, depending on the value of $res::Config->$env, or the environment set previously as either dev or live, the settings for the database connection are set. You store these settings in the Config array as db_live or db_dev.
However you do it, use an environmental variable to figure out whether you want live or dev, and set up and array of settings accordingly.
We also have sandbox and staging for intermittent development stages.
As for version control, use git or subversion.
Edit: It's also possible that within our vhost file, we setup an environmental variable as either live or dev, and our application reads from this accordingly. I'd suggest this approach :)
There are a number of ways of doing this. But this is a deceptively HUGE question you've asked.
Here is some good practice advice - go and research these items, then have a look at my approach.
Typically you use a precess called version control which allows you to create "versions" or snapshots of your system.
The commonly used "SVN" software is good, but the new (not really any more) kid on the block is GIT, and I personally recommend that.
You can use this system to push the codebase live in a controlled fashion. While the files/upload feature is essentially similar to FTP, it allows you to dump a specific version of your site live.
In environments where there are multiple developers, this is ideal - you can compare/test and work around each other, and version control tends to stop errors between devs.
So - advice part 1: Look up and understand version control, then use it to release CODE to the live environment.
Part 2: I use database dumps and farm them back to my machine to work with.
If the live database needs updating, I can work locally and simply export, then re-import on the live system.
For example: on a recent Moodle project I worked on, to refresh the whole database took seconds... I could push a patch and database update in a few minutes.
However: you should think about maintenance and scheduling... if the site is live and has ongoing data changes then you need to be careful with this. Consider adding a maintenance page.
Advice 2: go research SQL dump/export and importing.
I personally use phpmyadmin to dump and re-import, as it's very convenient.
Advice 3: Working locally then pushing live is MUCH BETTER PRACTICE. You're starting down a much safer and better road than you're on!
Hope that helps... but bear in mind - this is a big subject, so you'll need to research a fair bit.
Apparently there are two strategies used for deployment of web application. Please correct me if I am wrong.
Pull Deployment
I have my own build, deploy scripts. I use git as vcs. Deploy script will pull the code from git repository and build script will configure the app.
Pros
Easy installation.
Better scalability (as my ssh key resides in server, it can contact our vcs server). So even our application server grows we don't have to bother.
cons
Security issue as ssh key in every application server.
Push Deployment
I had used this method with my old project, where I used rsync to push the code. I push a copy from the local machine, but still we had used vcs.
Pros
Full control, flexibility as I don't have to push the code to vcs.
cons
Not better scalability.
I have checked some tools, which offering both strategies. (http://capifony.org/)
Questions
How do you guys handle this for a large scale project? (built with php).
Is there any better strategy?
Which is better in between these two?
What if there are many application servers under load balancer? will push make sense here?
Thanks in advance.
Full control, flexibility as I don't have to push the code to vcs
This to me is not a good thing. You will have more control using a VCS than without. I generally create a production branch alongside a development and feature branches, that way the production server only ever pulls down code that I've deliberately put into the production branch.
Furthermore, if you ever run into a problem where your production code suddenly breaks, if you're using a VCS you should be able to roll back to a working version while you figure out what's wrong with your code. This, to me, is one of the most beneficial aspects of using a Pull Deployment.
If you use a continuous integration tool like Jenkins, you can periodically check for changes on a specific branch in your VCS, and have Jenkins automatically pull and build your project for you, without anyone ever needing to log in to the production server themselves. This makes deployment as easy as updating your code in the repository.
security issue as ssh key in every application server
Depending on where your code is hosted, you might be able to set up deployment-only keys. This is how Bitbucket is set up, so our production servers can only pull code, not push. Furthermore, if one of these servers is compromised, we can easily revoke the access on our repository to that specific key.
Hello
I am not super experienced with PHP and large projects using it, most of my tinkering around has been in Rails with EngineYard (life seemed simpler back then). But in PHP, I haven't found anything that comes really well integrated with GitHub right out of the box. So I am looking for an easy solution to deployment for now and hopefully setting the stage for continuous integration in the future when I get around to writing the tests and such.
Here's what I have so far:
GitHub repo with my codebase
Alpha version of the app in CodeIgniter in PHP
Run of the mill webhost account with Site5 for staging/development
Currently, I deploy by uploading the latest batch of code via FTP onto my site.
For one, I would like to get to a one-step deployment process. Just a simple git push would do the trick. Is Phing overkill for now?
What are the steps you might recommend as best practices?
Thank you.
I recommend creating deploy script(s), especially at the beginning. It's a lot easier to start working on them since there are not that many things to do. Not to mention running a single deploy command is easier than doing all the steps manually. Even for small projects. Projects tend to complicate the deployment with time.
If it helps, we are currently using ANT (well, switching), we have dropped Phing due to not being developed/maintained anymore.
I use Beanstalk, and they have great deployment methods available. Once you commit, you can set up auto deployment settings, with a simple click.
Im thinking of updating my practices, and looking for a little help and advice!
I do a lot of work on sites that run joomla, oscommerce, drupal etc and so I have created a lot of custom components/plugins and hacks etc. Currently each site has its own folder on my xampp setup. What I would like to do is have a default setup of (for example) a Joomla setup and when I make changes updates, I can do something which updates all the other folders that contain joomla, almost like an auto update?
Im also looking at using Aptana IDE more and SVN service such as unfuddle to share my work with others, but I have not used SVN before and not sure if its possible to do the above using SVN?
It would be great to be able to work on a main/core item and send the updates to both local updates and to actual servers, without having to maintain lots of different individual sites.
Suggestions?
Yes, SVN would be a great tool for this purpose. Store your code (eg: a custom Joomla component) in source control. Wherever you want to use that component, just do a checkout or export of that particular folder into your live site. Here's one way you could structure your repository:
unfuddle.com/myRepo/trunk/com_myComponent
unfuddle.com/myRepo/trunk/com_anotherComponent
Log in to your live server via SSH and run this command:
> cd path/to/joomla/components
> svn co http://unfuddle.com/myRepo/trunk/com_myComponent
Any time you change your code, commit the changes and then log back into the server and run:
> cd path/to/joomla/components
> svn up com_myComponent
A real benefit of this is that should you do an update and break something, you can always roll it back to the last known "good" version.
As for automating this process, you might be out of luck if it's on different servers. For multiple deployments on the same server, you could quite easily write a shell script to run the above commands for each site/component. If you needed this to be fully automated, you could even set up a cron job to run this script every day at 2am or something - personally I'd stick with the manual approach, but it's still an option.
For working locally with your SVN repositories, I'd recommend looking at TortoiseSVN (if you're on Windows): it's the simplest and easiest way to work with SVN.
For automating things, you could use SVN hooks for this. There is a post-commit hook, so every time you do a commit, your hook script could tell the other machines to do an SVN update to get the latest code.
For more info, see Version Control with Subversion - Implementing Repository Hooks.
I don't have a good answer for your situation, but I don't think Subversion by itself is the answer.
This Question addresses some of the concerns about Subversion's mechanisms for sharing across 'projects'.
Subversion can certainly handle the source code management part of this puzzle. The automated distribution, well I'd use another tool.
Look into Capistrano. I've used it a couple of times and once you figure it out, it's pretty good. Aimed at rails but should work for anything where you need to get code from a repository and deploy it on different servers.