Changes between Version 5 and Version 6 of CodeManagementReleaseProcess

Timestamp:

11/25/11 18:35:10 (5 years ago)

Author:

jim

Comment:

--

CodeManagementReleaseProcess

@@ -21 +21 @@
  1. You may occasionally want to update the TEST and DEV site's databases and files to match the live server by using the DevelopmentServer#live2dev script.
 
----- update to HERE ---
-
-
 == Software & Getting Started ==
 You obviously must have Git installed on your machine to work on this project. The basic Git command line software available for most platforms in from http://git-scm.com/ - however, some very nice applications are also available that integrate into your operating system's graphical interface. Recommended '''FREE''' Git applications with a nice GUI are:
@@ -45 +42 @@
 This process gets you from a basic checkout of the code, through committing and testing, to a proper release on the LIVE server. By now you should have a copy of the code checked out as per the section above.
 
-The process is as follows:
+The process is as follows, and assumes you're in the root of your working directory:
 
 
@@ -51 +48 @@
 You MUST start by getting all the changes in the the origin GitHub repository...
  * If you've not already cloned the branch you want to work with, follow the instructions above in 'Getting Started'
- * If you have, you'll need to pull the latest changes:
+ * If you have and haven't made many changes, you'll need to pull the latest changes with a {{{git pull}}}
+
+
+=== 1. Creating/Working with your own branches ===
+If you're working on something and need to keep these changes from the rest of the development, always make your own branch on your local machine. Read the Git documentation for this, but the process is roughly as follows:
 {{{
+git branch [newbranch] <--- creates a new branch called [newbranch]
+git checkout [newbranch] <--- switches your working directory to it
+}}}
+You can then switch branches with no loss of work or confusion by using {{{git checkout [branch]}}}, where [branch] is the branch you want. You can see the branches available and active by using {{{git branch}}}. Use as many branches as you need to work locally, but please only send changes to GitHub when a) they're on live and development branches, or b) they're part of some new project or collaborative effort.
 
+
+=== 2. Edit you code, test locally ===
+As you modify the source code and theme files on working branch, the differences between your copy and the original branch (live or development) will grow. Clearly, if several developers are working on the same areas at once, you will have merge your changes carefully.
+
+To add and commit your code and merge 
+{{{
+git add -A
+git status <--- will show you what's changed, tidy up if needs be!
+git commit -m "a nice description of the commit"
+}}}
+The above makes sure your working directory code changes are copied to the staging area and ready to be merged.  Make sure you add a good description in case someone needs to roll back a commit to fix an issue. Then, repeat this step until you're ready to...
+
+
+=== 3. Merge your code and push back to Github ===
+When you're happy your work is tested and complete, you'll want to merge it back into a the 'development' branch for testing on the DEV server:
+{{{
+git status  <--- will show you what's changed -- double check!
+git checkout [target branch]  <--- should be 'development', but could be 'megaproject5' or even 'live' if you like killing kittens
+git merge [working branch]  <--- wherever you've been working and committing
 }}}
 
-=== Creating/Working with your own branches ===
-If you're working on something and need to keep these changes from the rest of the development, always make your own branch on your local machine. Read the Git documentation for this, but the process is roughly as follows:
+If the above goes well, your changes will automatically be merged in. If not, it's time to read up on how to manually [http://gitref.org/branching/#merge|merge changes]. Once the merge process is complete, you'll want to push your changes to the 'development' branch back to Github:
 {{{
-git branch [newbranch]
-git checkout [newbranch]
-... do your stuff ...
+git push -u origin [target branch] <--- pushes all updates back to [target branch] (probably 'development')
+}}}
 
-=== 1. Edit you code, test locally ===
-As you modify the source code and theme files on your checked out working copy, the differences between your copy and the Trunk will grow. It's wise therefore to do smaller chunks of work and commit once these specific bits are completed. Clearly, if several developers are working on the same areas at once, you will have to coordinate your work and be more careful.
 
-To update the Trunk (DEV) with the tested changes you've done so far [with information in square brackets]:
-{{{
-cd /the/directory/you're/working/in
-git add -A [this adds any files not already in the repo]]
-git commit -m "A sensible description of what you've done" [applies your changes locally]
-git push -u origin [pushes all updates back to repo, will need password]
-}}}
-Make sure you add a good description in case someone needs to roll back a commit to fix an issue. Then, repeat this step until you're ready to...
-
-=== 2. Test on the DEV server ===
+=== 4. Test on the DEV server ===
 This step is critical because the DEV server mirrors the setup on LIVE. Hence any issues or differences you didn't spot whilst working on your local machine can be ironed out here. It also allows you to get feedback on your work so far as required.
 
@@ -82 +93 @@
 ssh dev.transitionnetwork.org.webarch.net
 cd /web/dev.transitionnetwork.org.webarch.net/www
-sudo svn up
+git fetch origin  <--- 'origin' is github in this case
 }}}
-The last command brings the DEV site up to the latest Trunk version. Go to http://dev.transitionnetwork.org.webarch.net/ and enjoy the fruits of your labour.
+The last command gets all the updates to all branches  the DEV site up to the latest Trunk version. Go to http://dev.transitionnetwork.org.webarch.net/ and enjoy the fruits of your labour.
 
 Depending on the changes, you should test properly and then solicit feedback and testing from managers/stakeholders. This is probably on DEV, but could be on TEST if needed.
 
-=== 3. 'Tag' (copy) the release ===
-Once everyone is happy with the DEV site updates, you will nee/root/.my.cnfd to 'tags' (svn copy) the release so it's ready to be moved onto the LIVE server - or the TEST site if needed (more on that in a moment).
 
-You need to SSH into the DEV server and go to the website root folder (as above). Then run these commands to tag the release:
-{{{
-sudo svn cp https://tech.transitionnetwork.org/svn/www/trunk https://tech.transitionnetwork.org/svn/www/release/2010-11-23 -m "Release version 2010-11-23"
-}}}
-All releases go in the browse:www/release folder on in the SVN repository with the date as the sub folder name. The above commands will make a copy of Trunk as it stands and then move it to a new folder ready for release to TEST or LIVE.
-
-=== 4. Release to LIVE (or TEST) ===
+=== 5. Release to LIVE (or TEST) ===
 Please note the documentation for the LIVE server is here: wiki:NewLiveServer - and you should have decided whether or not it's necessary to do a run of testing on the TEST site before moving to LIVE... The process for both is the same, just on different machines.