[eluser]gwerner[/eluser]
I'm looking to get a better method to push web changes from my development server to my production server. My current method for handling this is quickly becoming insufficient. The way I do things now is make changes to the test server and then push those changes to the live server via a sync. This is great for linear changes, but not so great when trying to handle multiple tracks of scheduled changes.
What if I need to add a large section to my site. Or, I need to make a large change to the header or footer which are templates. Or, I have all of these changes occurring at once, but they are on different timelines to complete. These types of changes take more time to develop and I don't want to tie up my test server. If I need to make quick smaller changes then those have to wait on the larger changes to complete.
One thought is that I should run multiple instances of Codeigniter to handle the different tracks that changes are being developed. So, if I need to make small changes then I make those on the master instance and push those live and to the non master instances. Larger changes that require longer time to develop are done on separate instances and when ready push those first to the master instance on the test and then push the master to the live and back down again. This idea also seems like I might be overcomplicating things?
Hopefully this makes sense. Any expertise or guidance is much appreciated. Thanks!
[eluser]PhilTem[/eluser]
If I understood you correctly, your situation is basically yelling for
Version Control System
because with any VCS (like git) you can have multiple branches.
Imagine the following: You got a 'master' branch on your git which all production servers have replicated on their local system. Now you're making changes to your code in branch 'develop' and once these are stable you merge 'develop' into 'master' - and with post-commit hooks these changes will automatically be pulled from your production server making them run the latest version.
In case you intend to making changes over a longer period of time you just branch off 'develop' and make your changes there. Once it's running stably merge back to 'develop' and to 'master' - which will again be pulled to your production sites.
Git therefore cannot only be used for version controlling but also for something more similar like separating development into several parts which do not influence one another.
[eluser]lewisp[/eluser]
+1 for version control. We have a nice system for our CI projects that is a bit more involved, using Mercurial for version control. It's probably more than you need but it might be interesting nonetheless. We have a server hosting the central repository, and also running Jenkins deployment server.
Each CI project is a mercurial repository. We have 3 default branches, dev, staging and release. When a new feature is being developed, we add a new branch along the lines of feature-<somename>. We develop and test new features locally until they're pretty much done. Then we merge the changes into the dev branch to resolve any clashes with other features/changes that might have been added since we started ours.
Once we're happy, we merge the dev branch into the staging branch and push the changes to the server. The server detects the new push to the staging branch and runs Phing build scripts to do things like run tests, minify js/css, compress images and then upload files to the staging server. This allows us to test the new features using near-live database data.
Once that's done we merge staging changes into the release branch and push again, and trigger deployment when suitable.
It's a little fiddly to set up the Phing scripts but once it's done it makes life a hell of a lot easier as you can automatically trigger a lot of stuff using just a repository push. If you need more detail let me know!
[eluser]gwerner[/eluser]
I have looked into this in the past. I guess it's time to give it another peek. I've started reading the docs on Git. It seems fairly straight forward so far. Currently I've been working locally first. Then I will push that to a public lab server to allow reviews of the new content. Once the new content is approved I then sync that up to the public live server for the world to see.
If I go to something like Git, do I still need to use the three environments? Or, is better to only use two or even one? Maybe I need to read further first. But I'm at the point of install. And, I'm not sure which server to install to? My local, test, or live. Or will I have to do all three?
[eluser]PhilTem[/eluser]
You mean the environments of CI? I personally still use these environments as you want to check your scripts like they're running on the production site instead of in development mode.
However, you may not be able to check every single config of your production server (since it may have a differently configured apache and things alike), but you may check your code at least without too many errors 
[eluser]gwerner[/eluser]
Thanks for the help so far. I assume I only need to install Git one server? If so, do install locally or on the remote server?
[eluser]WanWizard[/eluser]
You don't need to install something locally, you can use online services like github and bitbucket. If you want to install a private git server, look at gitolite.
As for deployment, there are so many ways.
I've seen people using multiple repo's. In your production repo link to your development repo using a submodule. Because submodules refer to a specific commit, you can continue developing without interrupting production. To release, update the submodule reference.
You can also push to multiple repo's (your repo can have multiple upstreams), so you can use 'git push' to push updates to development, and 'git push production' to push to the production server. This has the advantage that you can avoid all kinds of merge hassles. This is handy if production runs on hosted platforms like pagodabox.
[eluser]gwerner[/eluser]
[quote author="WanWizard" date="1347474035"]You don't need to install something locally, you can use online services like github and bitbucket. If you want to install a private git server, look at gitolite.
As for deployment, there are so many ways.
I've seen people using multiple repo's. In your production repo link to your development repo using a submodule. Because submodules refer to a specific commit, you can continue developing without interrupting production. To release, update the submodule reference.
You can also push to multiple repo's (your repo can have multiple upstreams), so you can use 'git push' to push updates to development, and 'git push production' to push to the production server. This has the advantage that you can avoid all kinds of merge hassles. This is handy if production runs on hosted platforms like pagodabox.[/quote]
Ok, I am really green on this subject. Maybe I don't fully understand how to implement this. If I don't need to install anything. What is the download on Git for? I don't want to use any type of hosted online service as I don't want to expose any of the development. This should all be happening behind closed doors. Sorry for my lack of understanding at this point.
[eluser]WanWizard[/eluser]
Well, you need the git client locally.
Git is a distributed version control system. The way it works is that you have your own repository locally, in which you develop and commit your changes. Once your changes are to a level where you want to share them with others, deploy them, or even have a backup outside your PC, you push the local commits 'upstream' to another repository.
This repository can be on your own server (in which case you need git server software like gitolite), or in the cloud as a hosted service (like the two I mentioned, but there are others, both free and paid). Hosted doesn't mean public btw, in case of Bitbucket you get (limited) free private repositories, with Github you have to pay for that. But your own remote server isn't free either, and managing it costs money to. It's your choice. We run our own server which also runs Redmine, but we do managed hosting, so an extra server doesn't cost us much.
[eluser]WanWizard[/eluser]
There are a lot of IDE's (I personally use PHPStorm on Linux) that come with built-in git support, so if you don't like to use the commandline client (or use Windows where that is quite a complex task) you could select one of the many Git GUI's that are available to make it easier to use.
Github has a very good tutorial online about git and how to use it. If you mentally replace all references of "github" by "my git server", it should be clear how it works if you host yourself.
|
