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:
cd public_html git init git add * git commit -m ‘initial commit of the site’ cd .. git clone public_html testing mkdir dev
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
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.
- 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'