Web Development Workflow

Question

It is definitely time for me to learn about source control, and git in particular.

I do a lot of web development and most of the time I do a lot of development work on the live production server. I know this is really bad.

I just haven't quite got my head around how local development and then deploying to a live site with git works.

Is the following how it might work out:

1. Set up an environment on my local machine that is as close to my web server as possible

2. Create a git folder where I will develop my project (or download the existing project from the live server).

3. When I'm ready to push my changes commit them in git.

What I'm not sure about is the following:

• How to push my changes out to the live server?
• What if I accidentally delete my local copy?
• What about my database? If I add new tables and data on my local machine will I need to manually make these changes on my live server too?

---

EDIT

Yes, sorry, not enough detail.

I do all my coding in Coda for Mac, I have a few different projects on the go, but most of these are PHP/YII running on Apache. Database of choice is MySQL.

PHP is going out raw.

Answer 1

If your web site doesn't require compilation, you might just choose to deploy it directly from the Git repository.

• Do your development on your local box, as you usually would.
• Check your code into Github or another site like it frequently
• Since you don't need to compile your site, your Git copy is ALMOST ready-to-go
• You either want to exclude .git directories from APACHE service, or remove them after "git clone"

Your database is another issue. You will probably:

• Write scripts to make changes to your database rather than making them in a UI
• Include a version stamp somewhere (maybe in the database) identifying the current schema
• Name your scripts with database version numbers (I also keep an indicator of the associated code revision that is required for compatability - I automatically stamp it with Git changeset ID)
• In order, run all the scripts greater than the current database revision (but not greater than the current software revision. I scripted out this process too)

You do all this in bits and pieces on your development machine as though you were doing it in production. When it's time-to-go, you still really probably want test:

• mark your revision with a friendly branch name, like Release23a or whatever you choose, so you can find it later
• replicate your production database to a test environment (live data issues that can block upgrades partway through are a PAIN)
• deploy the whole package to a test environment, running MySQL scripts and doing your Git export (using your new branch name)

Then, you'll probably continue working and checking into Git as usual. Often, you'll be in the middle of implementing an ugly bit of code and need a quick patch to your live site. But you don't want to just go hack code into your live site. Instead:

• Check out your Release23a
• Make your hotfix
• Check it in as usual (it will save to the Release23a branch)
• Tag it again, Release23b
• Deploy as before (Release23b)
• Merge Release23b back into your main codeline

A quick note about branching. You can always go back and get ANY version you checked in by date/time, but it's easier to find them by name. Additionally, once you branch, you can do work on that branch, and then check it in again. Now you have a bifurcation in your codelines. You are making changes to yesterday's hotness, and it isn't automatically getting applied to today's hotness. If you WANT that, you have to manually merge it. Merging is the process of saying "Git client, please try to automatically apply all the code edits from the Release23a/Release23b delta to my latest hotness".

As you can see, you have some very cool tools available with Git. Deleting your local code isn't an issue, assuming you've been good and checking in frequently.

Note that Git has the concept of local commits. Those don't save your work from a hard-drive crash until you sync.

Answer 2

• How to push my changes out to the live server?

What I would recommend is either using GitHub to host your repository, or create your own private one. Then you would git clone a repository into your development folder, and the same on your production server.

You'd make changes to your local development folder, and when ready, push them to your GitHub repo. Then, you'd get onto the server, and pull in the changes from the GitHub repo.

• What if I accidentally delete my local copy?

You've got another up in GitHub and also on your production server.

• What about my database? If I add new tables and data on my local machine will I need to manually make these changes on my live server too?

Unless you have a script, which you can put into git, and you don't have any database replication happening, then you'd have to do it manually.

Answer 3

Here are few links helpful to answer your few questions.

For git usage : Git workflow

For guidelines for maintaining branches: Branching model

For updating server : Fabric

Answer 4

I'm also somewhat of a Git newbie. However, this Git workflow model seems unique and simple once set up:

http://joemaller.com/990/a-web-focused-git-workflow/

It may not be the right workflow for you, but once you learn how Git works, it may provide a low-maintenance solution.