Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

See SSP v2.4.0 Installation Instructions

Upgrade Instructions

All real-world SSP deployments fork SSP-Platform source code. Most end up forking SSP source code as well. Thus upgrades typically involve some amount of source code merging, at a minimum for SSP-Platform.

By definition, these instructions cannot provide comprehensive advice for all the situations you may encounter when upgrading source code forks, and they should be understand as a best-effort attempt at a generic recipe for working through any given upgrade, with pointers on known issues and "gotchas" mixed in.

In many cases, a systems administrator with relatively limited SSP-specific experience can successfully execute an upgrade. But again, because upgrading a source code fork almost always involves making decisions about what does and doesn't constitute a valid local change that should be carried forward into the upgraded source code, it may be necessary to involve a developer or technical staff already familiar with SSP internals.

The SSP team strongly recommends a multi-stage process for upgrading institutional SSP installations. Start by attempting the upgrade locally, even in the absence of a complete copy of UAT or production databases. Work out the obvious problems there, then move to your shared QA/Test/UAT/Dev environment and attempt a deployment. You'll usually want to refresh the database in that environment from a recent production backup, if possible, before attempting the deployment. Once everything has been tested successfully in that environment, you should have a very good idea of the exact steps you'll need to reproduce to execute the deployment in production. 

SSP Source Code Upgrade

If your deployment is not derived from a fork of the SSP source code project, skip this section and go to SSP-Platform Source Code Upgrade below.

Deployments typically upgrade/merge SSP source code before upgrading/merging SSP-Platform code because SSP-Platform has a build-time dependency on SSP.

In general, the SSP source code upgrade process steps through:

  1. Inventory local customizations
  2. Identify customizations to be preserved
  3. Merge latest upstream code into local development branch
  4. Resolve conflicts
  5. Test locally
  6. Commit, Push
  7. [Upgrade SSP-Platform]
  8. Test in shared QA
  9. Merge development branch into prod branch
  10. Deploy to PROD

SSP Source Code Upgrade - Example

The following is a schematic example of the high-level source code merge process.

No Format
# By convention, the 'origin' remote typically points to your fork in your Git hosting service,
# and upstream points to the canonical Apereo SSP repo in Github. E.g.:
#    $ git remote -vvv
#    origin	git@github.com:edu.edu/SSP.git (fetch)
#    origin	git@github.com:edu.edu/SSP.git (push)
#    upstream	git@github.com:Jasig/SSP.git (fetch)
#    upstream	git@github.com:Jasig/SSP.git (push)
# 
# Get the latest remote code
$ git fetch origin
$ git fetch upstream
 
# Make sure you're on your dev branch. The convention is <institution>-ssp-dev
$ git checkout edu-ssp-dev
 
# If that errors out, with an error like:
#    error: pathspec 'edu-ssp-dev' did not match any file(s) known to git.
# Then you probably need to create the branch and link it the remote copy that should already exist in 'origin':
$ git checkout -b edu-ssp-dev origin/edu-ssp-dev
 
# Capture local changes. This will help with two things:
#
#   1. Deciding whether to merge or reset-and-cherry-pick, and
#   2. Sanity checking the result of either approach
#
# This can be a bit complicated (http://stackoverflow.com/questions/1527234/finding-a-branch-point-with-git)
# but usually it's sufficient to get the diff against the current state of the upstream
# branch on which your dev branch is based:
#
#  $ git diff upstream/<most-recently-merged-branch>..HEAD
#   
 
# E.g. for a local dev branch based on rel-2-3-patches:
$ git diff upstream/rel-2-3-patches..HEAD > /my/upgrade/notes/pre-upgrade-local-diff
 
# Or, get a list of all the commits in your dev branch that aren't in the most
# recently merged upstream branch. Again, for a 2.3-based dev branch:
$ git rev-list upstream/rel-2-3-patches..HEAD
 
# Or:
$ git log upstream/rel-2-3-patches..HEAD
 
# It may also be useful to use a tool like Atlassian SourceTree to help visualize how your dev branch has diverged
# and inventory the patches to be preserved.
 
# If local changes are minimal, such that a merge is likely to create more problems
# than it solves because of unrelated conflicts in upstream code, it's often easiest
# to just reset your dev branch to point to the target upstream branch and cherry-pick
# local customizations into the result. E.g.:
#
# Create a branch to hold your place:
$ git checkout -b edu-ssp-dev-pre-upgrade
# Switch back to "main" dev branch
$ git checkout edu-ssp-dev
# Force dev branch to point at upgrade target. E.g. for a 2.4 upgrade:
$ git reset --hard origin/rel-2-4-patches
# Re-apply local changes via cherry-pick. E.g. for each commit in
# 'git rev-list upstream/rel-2-3-patches..HEAD' from above:
$ git cherry-pick <commit>
# If git reports conflicts on a cherry-pick command, you'll need to:
#  - Get the list of unstaged files. These are the conflicted files:
$ git status
#  - Open each conflicted file, correct the conflicts and
#    'git add' the corrected files (http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging):
$ git add <corrected-file>
#  - Complete the cherry-pick once all conflicts are corrected. You should
#    be prompted to edit the commit message.
$ git cherry-pick --continue
 
# Or, if local changes are extensive, such that history is important and isolating each
# relevant commit for cherry-pick is not feasible, use a standard 'git merge'. Again
# assuming an upgrade to 2.4.x:
$ git merge origin/rel-2-4-patches
# Deal with conflicts in the same way as described above for cherry-picks:
#  - Get the list of unstaged files. These are the conflicted files:
$ git status
#  - Open each conflicted file, correct the conflicts and
#    'git add' the corrected files (http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging):
$ git add <corrected-file>
#  - Commit the result once all conflicts are corrected
$ git commit
 
 
 
 
 
 
 
Note

In progress

SSP-Platform Source Code Upgrade

Note

In progress

...

Upgrading Source Code Forks

See SSP Source Code Upgrade Process

Additional Upgrade Steps

Warning

For all existing installations of 2.0.X and 2.1.X, important upgrade instructions exist in the previous 2.12.2 and 2.3 Release notes. 

  • To upgrade from 2.0.X follow the upgrade instructions for 2.12.2 and  2.3 Release Notes before deploying the 2.4
  •   To upgrade from 2.1.X follow the upgrade instructions for the 2.2 and  2.3   Release Notes before deploying the 2.4
  •  To upgrade from 2.2.X follow the upgrade instructions for the  2.3  Release Notes before deploying the 2.4 code

...