2

I'm a lead developer for a small company and I've recently came across a way to implement version control (git) on our workflow because the company is growing. In terms of infrastructure we have a couple of "production" servers, a development(accessible over the internet) server and an internal development server with internet access but blocked by a hardware firewall. Our current workflow consists of:

  1. init a repo inside the production server with the proper .gitignore for that project and do the initial commit
  2. push that commit to a bare repo inside the development server
  3. clone the repo from the development server to the internal development server
  4. make a network share on samba on the internal developlemt server so other network computers (we are all running windows) can connect to it.

I know for sure that this is a bit too complicated, but we want to try out git and make the workflow as easy as possible.

I've been reading about git-flow and stuff but so far I've been unable to get the workflow just right, I think that having the two development servers adds some redundancy.

Can someone share any tips on how to improve this workflow?

Improve this question
3
  • What kind of servers are these (Web Servers? Git Servers? Some Other Servers?) and what are you trying to accomplish? Are you trying to stand up some git servers? – RubberChickenLeader Apr 7 '15 at 18:36
  • These are web servers running Nginx, php-fpm, MySQL and memcache/varnish. I'm trying to setup a structured workflow to establish some "rules" in case the company decides to hire more developers. – ddrjm Apr 7 '15 at 21:44
  • It is now starting to make some sense why you were confused about git-flow. git-flow is a development workflow not a deployment workflow. Ill type up an answer about deployment workflows for git. – RubberChickenLeader Apr 8 '15 at 14:54
0

While I have not used this method in production I have been looking at using git to deploy code to our prod server. The basics is that you set up a bare git repo on any server you want to deploy to and then add that as a remote to another repository. When you are ready to deploy you just push your code to the remote repository. From my research I am looking at setting up a git repository on a server for developers to push to and then using git hooks on master and develop to push to my prod and dev servers (based on the branch).

The key to understand is that the "Basic" workflows for git are more targeted to developers than to deployment since git is primarily an SCM system.

The process I am working on uses a central git server with a post-receive hook to push to remotes on each dev or prod server. Then on the prod server I use a post-receive hook to checkout the newest code into the proper directory.

For more information and some detailed directions https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks has been rather helpful for setting up the dev and prod servers as well as good information on post-receive hooks (which are simple bash scripts executed after a push is complete).

EDIT: Expansion for the comments. In the above I am not pushing from the dev server to production. I have a central git server that all my developers push to. On that git server I have a git hook to push to my dev servers (remotes set up only on the central server) when a push to my development branch is made and production servers when a push to master (production branch) is made.

For development we use the git-flow workflow and all devs have a local (on their development machine) instance of the web server software we use. Any changes they make are only on their feature branches and are not merged and pushed to develop (our development branch) until the change is complete. Initial testing is done on their local machine to ensure the code is ready and then depending on the change on the code reviewers machine after a test merge with develop (make a new branch from develop and merge the feature branch in. If there are no issues then merge the new integration branch into develop and push to the server)

Improve this answer
6
  • 1
    Hmm this is indeed useful for deployment, but from what I understand in your post, you seem to be pushing from development to production which means you won't have any chance to test what could be wrong I think. – ddrjm Apr 8 '15 at 23:52
  • For example: Have developer A and B. A is working on a feature, B is working on another feature, how do I manage debugging and the code consistency on the dev sever? lets Say dev A has pushed some code that will break the website, and dev B pushes also the code that will add a new feature, (both are on different branches), how would I make sure that Dev B doesn't see the error that Dev A made so he can test freely? – ddrjm Apr 8 '15 at 23:59
  • Why don't you provide it with an empty document and perform required changes? – Basilevs Apr 9 '15 at 3:19
  • 1
    @ddrjm you mention development as well. I will edit my answer and add additional information. – RubberChickenLeader Apr 9 '15 at 11:24
  • @WindRaven, I now understand what you are saying but there is one small technical issue that is bugging me: Both production and development servers are using an nginx stack (on linux) and most of the team computers are running windows, I like the idea of having a local dev environment (I'm used to XAMPP), is there any reliable stack (like xampp) for nginx on windows? The reason I'm asking is because that way it would be easier to setup on all the windows computers :) – ddrjm Apr 9 '15 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.