Your version control setup?

I’m curious to see how you handle your versioning and deployment. I currently work with Git, and am thinking of setting up a new environment as such:

Prod Box
Dev Box
Git Box - will hold all git repos except for a copy of dev, (uat, prod)

Workflow would be that development is done on Dev box, in a new git repo (housed on Dev Box). From here updates will be pushed to the project UAT repo on Git Box, and then a pull would be done after this from UAT. Same process from uat to prod (push from git box’s uat repo to git box’s prod repo, and then a pull request from prod machine.

I feel like there may be a better more effecient way of doing this. Whats your method or how would you do it if you could change?

It seems due to the lack of responses here, that this is not a very common tool used here. I highly recommend using version control for your projects, even if they are small.

I found this resource to be most useful:

I am a huge fan and avid user of Git.
In my experience, the rather standard approach is to setup three server instances (they can be physically different boxes or simply instances in the cloud)

[] Development
] Staging
[*] Production[/List]

All work is done on the development server, changes are ‘staged’ and tested on the staging server and finally moved to production when validated.
The idea of ‘pulling’ from a git repository on all three is the logical choice.

I would say it is not necessary to host your git repositories on its own box. Many use Github or Bit bucket for this.

I’m wondering if this would be a simpler approach:

Dev/Git Box - gitmaster (user account): will house one copy of git repo

Example project foo:

  1. git0.local - /home/gitmaster/foo
  2. git0.local vhost points to /home/gitmaster/foo (this will act as uat site)
  3. git clone is done to users dev machine (user uses built in php -S as dev site)
  4. prod.local does git pull from git0.local

This takes it down to just 2 machines (3 including the developers box) and only 2 types of git ops will be down (pull from git0 to prod, and push from developer box to git0)

Don’t feel compelled to have a server for the repository. One of the real differentiating features of git is that it is truly distributed; EVERYONE has [can have] the entire history as part of the local repository.
If you have only two (or three) developers it is probably MORE EFFICIENT to just pass patches or Pull Requests around. On the other hand, I have successfully use Dropbox as a git host.

I’ve never used GIT but it seems like an overkill. Why not just tag by per release (ex. SVN tag)? I don’t understand why you have to build on the environment server as well. Whatever code was deployed on dev should be EXACT same code on qa and prod. For example, I make Java Web app called say “myWorld.war”. I deploy this to dev. If it passes the tests, then I copy myWorld.war to qa and so forth to prod. If I feel super lazy then I’ll drop the war file into shared directory like myWorld-1.01.war, myWorld-1.02.war, and so forth.

And then what repo does your team pull from to start working from? Dev will not be the same as uat and prod as its being worked on. have a look at the link I posted earlier to see why git is useful. It allows for multiple team members to work on features at the same time, and then merge them. Not too mention the all too awesomely amazing feature of being able to pull from a specific version.

Simple. 1 repo. I guess GITs multiple repo = SVN Tag. If I tag a SVN repo, then a developer can get the snapshot of the code at any given time. We do this only if there’s a critical production issue. We also do a copy of repo per production release to be used as debugging resource or verify the code logic. Lastly, we have tons of automation tests that does a good job of not checking-in bad code. For example, you can’t check in the code where code coverage is less then say 90%. Can’t check in if a test failes from collection of unit/integration (hundres of them). Every code has been code-reviewed, You can’t simply just check-in a fix code w/o testing code. We also run various code analyzation tool to detect bad codes. Basically, we’re using something called SONAR. If 2 developers need to share code (not w/ rest of the team) then we use Maven to deploy artifacts. At least this how our Java world works.

Git supports tagging and in two different ways. Don’t confuse multiple copies of a repository with multiple repositories. With git you traditionally have a primary repo store and (because git is distributed by design) each developer has a copy (or shallow-copy) with a link to that primary store known as ‘tracking’.
The single most misunderstood property of git - and one of the primary ways in which it differs from other VCS - is that each stakeholder holds a copy of [b]the entire history[/i] at any given time. That is the DISTRIBUTED nature of git; instant access to the entire history and implicit redundancy plus total portability.

First, check out – that is a great approach to handing webapps in git (or mercurial)

As for us, we generally use mercurial and the ultimate SCM hosting is bitbucket. Every project is typically one repository, and it has all necessary information to build the project for local development or our integration / staging / production environments.

I would argue pretty strongly that having integration tests not letting folks check in code with less than 90% coverage is counterproductive. Now, having integration tests that prevent code that doesn’t meet spec from getting deployed to production is a whole nother beast.