1

Were a small wordpress development team who currently build our projects on a development server using mamp and once a project is ready to be live we FTP the site files to the production server. Currently when a dev needs to work on a file he/she will pull it from the dev.development.com server and once finished reupload the file so the client can approve the changes before FTP'ing the file to the production server.

We're experimenting with GIT and bitbucket solutions and are wondering how we can use these tools to have source control with our code. We've tried various things over the past couple of days and are having issues on how we can maintain a codebase on the development server and have developers work locally. The dev server is a networked one connected to all our macs and has the mysql database that we use to connect our WordPress sites to.

Has anybody have experience of this or know how we can have source control with our setup - we're keen to modernise our approach but we like the idea of having our development server to work on.

Thanks in advance.

Edit - for the SO trolls here is the question: How to setup git when you have developers and a local development server that clients access?

jamper
  • 277
  • 2
  • 5
  • 24

1 Answers1

2

A typical release life-cycle with GIT might look something like this

Development:

  • all developers work against a local copy of the GIT repository on their dev system. You would have them run the "pull" command regularly to ensure they're working against the latest code: http://git-scm.com/docs/git-pull
  • when they complete a change they commit it back to the Bitbucket repository via the "push" command: http://git-scm.com/docs/git-push. Ideally they would specify a commit message so you have traceability as to what they're changing.

Promotion to test server

Promotion to production

  • when you have a release candidate--a set of changes which the client has signed off on--you would then "tag" them in the repository. A tag basically says "the codebase is stable and ready to be released": http://git-scm.com/docs/git-tag. N.B: you'll want to ensure that you're tagging the exact revision that was tested, so be sure to keep track of it. (Alternatively, you can be more strict about it and only ever deploy tagged versions to the test server, but without a separate system integration environment/step in the release process this doesn't add much value.)
  • you would then deploy that specific tag to production, more or less in the same manner that you deployed to the test server above (overwriting prod with the contents of the tagged version in the repository)

Here's a good primer/reference on GIT that may be of use to you: http://rogerdudler.github.io/git-guide/

Hope this helps! If anything is unclear just let me know and I'll edit my answer.

Community
  • 1
  • 1
Adam M
  • 66
  • 4
  • Thanks @Adam M - I understand how to use git in a solo dev environment. Could multiple dev's work on the dev server or would they have to set up local version to work with and then push to the repo. from there the dev would pull to the dev server?? – jamper Aug 08 '14 at 14:43
  • Ideally everyone would have their own local environment, yes. One of the key benefits of version control is that it allows teams to work on the same parts of the system without having to worry about, say, locking the same physical file, accidentally overwriting another developer's changes, etc. If that's not possible due to infrastructure constraints you could consider setting up multiple dev environments on your single physical dev server. That way you're still getting the full benefits of version control without the need for many local environments. – Adam M Aug 08 '14 at 14:54
  • (P.S. sorry if my GIT usage details were too verbose, just wasn't sure of your experience level with it) – Adam M Aug 08 '14 at 14:54
  • Thanks :) so just to clarify, devs will have local versions of the code they are working on. 1 master branch that will serve as the live code. multiple dev branches with features etc. Can the dev server we have pull a particular branch to show the client etc? – jamper Aug 08 '14 at 15:10
  • There are a few different ways to approach branching, it depends what the team is working on. A typical use case is to branch for large features but work in the master branch for minor changes. When the large features are complete you would then deliver them back to the master branch. As far as deployment to the dev server, you can deploy anything (master branch, feature branch, or tag). I would only ever recommend deploying tags to the production server, as this is a general version control best practice (regardless of GIT vs SVN vs whatever else) – Adam M Aug 08 '14 at 15:44
  • By the way, if you've found my answer helpful please be sure to accept it. If you'd like me to add more detail just let me know. – Adam M Aug 08 '14 at 15:46
  • Thanks - your answer has helped immensely. So with post hooks I could set up them to receive the development branch and have the production post hook to receive the live branch? – jamper Aug 08 '14 at 15:52
  • Not sure I completely understand but you could definitely use a post-receive server-side hook to have the dev server updated automatically whenever a change is committed. Because you're using Bitbucket there'd be an extra step involved: you'd need to have Bitbucket do an HTTP POST to your server (using https://confluence.atlassian.com/display/BITBUCKET/POST+hook+management) which in turn would execute a script on the server to automatically update the environment. I wouldn't recommend doing something like this in production, though, you always want to trigger production deployments manually. – Adam M Aug 08 '14 at 16:18
  • Thanks for your clarity - how would we trigger production deployments manually, via SFTP etc? – jamper Aug 12 '14 at 08:57
  • Typically one would build a script (shell scripts or batch file, depending on OS) that: * puts up a "Site is down for maintenance" page * exports a copy of a specific tag from GIT (using the "archive" command, described above) * updates the contents of the web server * takes down the maintenance page – Adam M Aug 12 '14 at 13:38