PHP remote development workflow: git, symfony and hudson
- by user2022
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 www.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 www.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'
