I'm posting this to the list even though I suspect only one person will have an answer, but what the heck, let's all share the knowledge.
After working on dug.lv at the last meeting, I started to see some of the advantages Casey has been trying to beat into all our heads for some time. Yes, I've known about at least most of them for some time, but I haven't embraced many of them. However, I'm starting to see where some of those inconveniences can actually be beneficial (especially when dealing with multiple people working on a single site), so I thought I would take one of my external projects and apply the principals there.
One of my clients has three websites (and soon to have a fourth) in this arrangement:
- A public Drupal 7 site on Linux.
- A private Drupal 6 site on Linux.
- A private Drupal 6 site on Windows.
- A soon to be private Drupal 7 site on Windows.
The Drupal version doesn't really matter, but I listed it anyway. There are two sites each on two different servers. They are not multi-site installs (they don't share code). There are reasons for the setup being the way it is that are inconsequential to the query at hand. The short answer is the current setup is not changing.
So, my basic question is how should I setup Git on the servers to be able to do pulls and pushes on a remote computer so I'm not operating live and so I have some sort of backup and recovery. (Yes, I play with fire, too.) I could host the code on Github, but since I'm dealing with a health care company and have HIPAA to deal with, I don't really want to take the chance that some patient data might get accidentally posted, so I'm not considering that as an option.
I can imagine two ways of doing it, but maybe there's another (better?) way I haven't thought of.
- The first way I thought of doing it seems pretty straight forward, and that is to setup a Git server on both of the two production servers and deal directly with each server separately from each other, something like this ghetto diagram:
Git on Windows production <---> Development
Git on Linux production <---> Development - But then I thought of another way of doing it, introducing a staging step and extra backup simultaneously. That was to add a third server, making it a connecting or intermediary server, and have Git installed on all three servers, something like this:
Git on Windows production <-+
+-> Git on Linux staging <---> Development
Git on Linux production <-+
So that development pulls and pushes go to the intermediary server, and then the intermediary server pulls and pushes to the production servers.
The one drawback is that there would then be an additional step to getting changes to production (more things to go wrong), but I think the safety net it provides off-sets that potential problem quite a bit.
Does anyone have any suggestions and/or recommendations for this situation and for making it happen? I'm finding support for something like this on Windows to be a bit sketchy.
Comments
You made me break my silence :-P
Curse you Oadeah, why did you have to make such an interesting post that it distracted me from my studies. :-P
I know less about Git than anybody lol, but theoretically that functionality should be as simple as writing some shell scripts. I am assuming Git has both client and server code, as that is main idea of the methodology of Git (duh). So the staging server should also have Git client functionality on it.
If you could just write a script that hooked into a "Git server update event" and then push to the corresponding production server, that would be your solution.
And after a quick Google search it would seem that Git servers have hooks that work very similar to CMSs' like Drupal. (which is kind of awesome actually)...
http://book.git-scm.com/5_git_hooks.html
Here is a tutorial that does something similar to what you seem to want, though not exactly. It has the production server run a php script to auto-pull from the git repository when the repository changes (a hook on git-push). You want the inverse, but the concepts are very similar, and it is a good starting point:
http://theme.fm/2011/07/github-playground-servers-auto-pull-from-master-...
So that means your only real challenge is the challenge of setting up Git properly on all the machines lol.
And one day...I will actually have time to learn Git. I like it more every time I read about it lol.
Now back to my cave. I have study for my Combinatorics and Graph Theory Final.
"If you give someone a program, you will frustrate them for a day
but if you teach them how to program, you will frustrate them for a lifetime."
(Programmer's curse)
Welcome to the wonderful world of deployment with git
The beautiful thing about git at the center of your development and deployment workflow is that you can bend it to fit your needs.
github, and many other services, have private services for those that need their code private, but these always cost $$ and have limitations on storage space, number of developers, etc.
Git server is built into git-core, so if it is installed on your client or server, you can push/pull from it. Making it secure and user permissioned is just a matter of normal linux configurations. for example, I run a "git" user on my localhost so i can:
git clone git@localhost:/path/to/git_project.gitSo i can pull and push to a different location on my local server. I could easily put something like this on an external server and push to it. then you ssh on your live sever and pull from itself.
This approach works great for single developer situations where you want a private git process. You can set it up for multiple users, but it can get messy and difficult to add and subtract people quickly. Hence, services like github exist.
Here is a a great tutorial I used when setting up my own git server: http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private...
My next git adventure is to tackle Gitosis (http://eagain.net/gitweb/?p=gitosis.git) ... it is a full featured way to host git repos with multi user and permissions config on the front end. It is supposed to be awesome. I will report back how it goes.
Lastly, i wanted to mention another tool that helps with what i think Ray was calling "git hooks" (pardon me if i misunderstood). Jenkins - http://jenkins-ci.org/ - is a server side tool that helps with pulling code from git to different locations on in you deployment process. For example, we can have a branch on dug.lv that is called dev and every 5 minutes it will automatically pull and build in the HEAD from the dev branch and that code with be live at dev.dug.lv ... that way, I (or anyone else with ssh access) does not have to manually do the pull.
It is really sweet and hope to have that function up and running soon on my(our) server.
That's all I got for now. Cheers, happy gitting!
-Casey
FYI
In that tutorial you refer to, he mentions in his Update 2: "Gitolite seems to be a better solution for multi-user hosted Git than Gitosis."
that is correct
My bad, it has been a while sunset I read the article and remember thinking there was another option. I would like to try both as I have only used thebuilt in features.
sunset...?
Curse you auto correct.
Finally!
Having just completed my final 'git clone', I wanted to reply back as to what I finally went with and how I got there.
I started with the idea of only having git installed on the two production servers and my development computer (my method 1 above), considering git incorporates a (code) backup of sorts (which I believe was a main point Casey was stressing).
However, about halfway through I changed my mind and went with an intermediate git server between the production servers and development computer (my method 2 above), for a number of reasons, which are:
I also created branches for each of the sites based on the major Drupal version in use. That will help immensely when it comes time to do upgrades.
Here are the primary web pages I used to help me along this path:
Of course, I searched for information and used other pages when what I found wasn't entirely clear, but the above pages were the ones that did the most to get me through the process.
The two areas I struggled with the most were SSH and Git on Windows. The thing that stumped me the most with SSH was that I forgot to update this line in the /etc/ssh/sshd_confige file:
AllowUsers myuser gitI was already very familiar with the other aspects about setting up SSH, but that one got me twice. I guess I've never had to do it before.
In setting up Git on Windows, there seem to be two primary approaches that people talk about: Install Git's Windows version (Msysgit) with CopSSH, or use Cygwin. I didn't want to use CopSSH, because the part that's free requires recompiling on Windows, and I wasn't interested in going through that process (and none of the tutorials I found covered that part at all). I wasn't able to use Cygwin, because every time I tried to install it, it would cause the server to reboot - not a good thing. I finally discovered that Msysgit has whatever SSH it needs built in (at least for my needs as a client), so that's what I used.
My next steps are to start pulling all the code pieces out of the database and make them modules of their own or part of existing modules. That's something I've been wanting to do for a long time, and with the new setup, it should be easier to make it happen.