CODEWITHSUNDEEP
gitversion-control
marcin_koss
marcin_koss

Reputation: 5882

Setting up GIT and workflow for bigger web based application

We have a biggish internal web based system that currently is maintained by a team of 3 developers. Our current setup is 1 development server and 1 production server - possibly soon 2 prodution servers behind load balancer. Our current workflow is all developers update files live on dev server. Whenever we are ready with the changes we rsync codebase to production. We develop fast and change things very often. For quite some time we've been wanting to start using version control to have more control over the changes we make and the overall code quality. The only question is how to do it properly and what would be the most efficient way since we still have to keep things moving fast.

Some of the question I have are:

Here's the setup I came up with. Please let me know what you think and suggest improvements. enter image description here

Upvotes: 3

Views: 943

Answers (2)

GayleDDS
GayleDDS

Reputation: 4533

Horrer all developers update files live on dev server. No source control

At'a Boy to you for fixing your architecture and workflow. I was in this exact situation in a long ago job.

  • Yes, you should definitely checkin your 3rd party libraries, images etc. You rarely touch them because the world comes to a crashing end if you update them. You can't bring a second production server online unless you can build it exactly like the first one. Every thing need to be running the same version of all the same software. In my project we had everything that got installed on the server in source control.

  • Yes it's ok to just use master, you don't want to change too many moving parts at one time. As time goes bye revisit this to see if your ready / need a branching workflow.

  • You can't use a bare repo. There would be no files for the web server to run off of.

Great job, good questions and design.

I would definitely use sub domains for each developer. Another place I worked at, a commercial software company, wicked smart people, did it this way.

My one suggestion would be to have stage.project.com running on the Production server. It would use the production data sources and let you test in a production environment.

Also everyone on the Team should have to watch. Git ages 4 and up http://www.youtube.com/watch?v=1ffBJ4sVUb4 and for extra credit watch Advanced Git http://vimeo.com/37408017

Upvotes: 1

innaM
innaM

Reputation: 47829

What I don't like about your plan is the deployment stage. Why? Because 1) it's a manual process and 2) it's pull-based. I'm also not sure what I think about version control repositories on a production server.

What I would like to suggest is to build a little script that rsyncs to the production servers, including rsync's --delete and --exclude .git/ options. If you wanted, you could write the SHA1 of the current commit to a little file so you can always know what is online.

Ideally, that script wouldn't sync directly to your document-root, but to a freshly created directory that you then symlink your document-root to. Name that directory using a timestamp and maybe the commit SHA-1. That way, if anything doesn't work out the way it was supposed to, you just have to adjust the target of your symlink.

Upvotes: 1

Related Questions