: PHP remote development workflow: git, symfony and hudson I'm looking to develop a website and all the work will be done remotely (no local dev server). The reason for this is that my shared

@Dunderdale272

Posted in: #Git #Php

I'm looking to develop a website and all the work will be done remotely (no local dev server). The reason for this is that my shared hosting company a2hosting has a specific configuration (symfony,mysql,git) that I don't want to spend time duplicating when I can just ssh and develop remotely or through netbeans remote editing features.

My question is how can I use git to separate my site into three areas: live, staging and dev.

Here's my initial thought:


public_html (live site and git repo)
testing: a mirror of the site used for visual tests (full git repo)
dev/ticket# : git branches of public_html used for features and bug fixes (full git repo)


Version Control with git:

Initial setup:

cd public_html
git init
git add *
git commit -m ‘initial commit of the site’
cd ..
git clone public_html testing
mkdir dev


Development:

cd /dev
git clone ../testing ticket#
all work is done in ./dev/ticket#,
then visit domain.com/dev/ticket# to visually test
make granular commits as necessary until dev is done
git push origin master:ticket#
if the above fails:
merge latest testing state into current dev work: git merge origin/master
then try the push again
mark ticket# as ready for integration


integration and deployment process:

cd ../../testing
git merge ticket# -m "integration test for ticket# --no-ff (check for conflicts )
run hudson tests

visit domain.com/testing for visual test

if all tests pass:
if this ticket marks the end of a big dev sprint:
make a snapshot with git tag
git push --tags origin
else
git push origin
cd ../public_html
git checkout -f (live site should have the latest dev from ticket#)
else:
revert the merge: git checkout master~1; git commit -m "reverting ticket#"
update ticket# that testing failed with the failure details


Snapshots:

Each major deployment sprint should have a standard name and should be tracked.


Method: git tag
Naming convention: TBD


Reverting site to previous state

If something goes wrong, then revert to previous snapshot
and debug the issue in dev with a new ticket#. Once the bug is fixed, follow
the deployment process again.



My questions:


Does this workflow make sense, if not, any recommendations
Is my approach for reverting correct or is there a better way to say 'revert to before x commit'

Vote Up Vote Down

Login to post a comment!