SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,176
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)

    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
    UAT 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?

  2. #2
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,176
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    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: https://www.atlassian.com/git/workflows

  3. #3
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,329
    Mentioned
    191 Post(s)
    Tagged
    4 Thread(s)
    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


    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.
    Last edited by cpradio; Sep 17, 2013 at 08:37.
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  4. #4
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,176
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    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)

  5. #5
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,329
    Mentioned
    191 Post(s)
    Tagged
    4 Thread(s)
    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.
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  6. #6
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,394
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.

  7. #7
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,176
    Mentioned
    63 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by sg707 View Post
    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.

  8. #8
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,394
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.

  9. #9
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,329
    Mentioned
    191 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by sg707 View Post
    Simple. 1 repo. I guess GITs multiple repo = SVN Tag.
    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.
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  10. #10
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,623
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    First, check out http://nvie.com/posts/a-successful-git-branching-model/ -- 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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •