Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>We control our code base with one instance of SVN and use another to control the environments and the contents of the web servers for each testing stage and eventually production. Having the history of what has been on each environment has saved us a number of times. Keeping your log messages meaningful will definitely pay off.</p> <p>I export from the automatic build sent to our Dev server onto a checked out version of the System Test files and then commit the changes to that. Updating the servers in the web farm is just a case of updating to the HEAD revision on all the boxes. Staging is updated using an export from System Test and then Production is finally updated from a Staging export. Some parts of this are scripted but having manual oversight is convenient. Probably the hardest bit is ensuring the config files are correct for each environment but if you aren't changing it you don't deploy it.</p> <p>You will probably still want to get to grips with feature branches or release branches and the necessary <a href="https://stackoverflow.com/questions/1522775/branching-and-merging-strategies">strategies</a> to recombine the source. You may need to bug-fix something in Production you never expected no matter how good your testing strategy.</p> <p>One thing to note is not using client version 1.6x with a 1.5x SVN server as this is playing havok with our merge processes until we upgrade see; <a href="http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx" rel="nofollow noreferrer">http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx</a></p> <p><strong>EDIT:</strong></p> <p>Each server in our deployment environment has the TortoiseSVN client installed so that the sysadmins have a GUI for updating the checked out repository. </p> <p>I have also made them some scripts that use the SVN command line utilities to update a few repositories on the servers with an automated job. This allows our content team to commit files to their local copies of the server resources folder and then this updates every hour. They only have access to a that specific set of folders which we control with the auth file on the SVN server. </p> <p>We have two separate machines that actually have SVN server installed which are backed up daily. One is for repositories of source code and the other one for the eventual builds that are deployed in each environment. It does mean we have a complete duplicate repository for the deployment in each environment but storage isn't an issue.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload