This is a note to any IDM staff who become responsible for making Shibboleth configuration changes. This reflects the current practice that uses just the /trunk and /tags/Release entries in the SVN repository for the yale-shibboleth-installer. All other directories and tags are obsolete and will be cleaned up sometime when we are sure nobody cares about the history.
A new "Release" of Shibboleth at Yale is really a new version of the configuration files. The actual Artifact of the Shibboleth application changes very infrequently, but new Relying Parties (Yale applications and cloud partners) are defined every week.
In the current arrangement, all the metadata and configuration files are the same for all three instances of Shibboleth, or as much so as possible. Generally Development versions of Relying Parties tend to point to DEV Shibboleth for their SSO, but PROD or TEST Shibboleth would authenticate them if they pointed to either of them. There are a very small number of parameters that select specific URNs, URLs, or file names that have to be different in each Shibboleth instance (like, for example, the IDP's own Metadata file with its own certificate, or the database URLs). These instance-specific values are set from the DEV, TEST, or PROD .properties file and are substituted into the configuration files and data sources as the Ant script copies files over during each install job.
Because the Artifact (WARs and JARs) don't change, there is no Build job. There is just an Install. While there is a WAR, the Shibboleth configuration files go in the IDP directory outside the Web Server and so are checked into Subversion as files (they are not zipped up) and are copied as individual files by the Ant script the Installer runs.
The Jenkins Install jobs check out the configuration files in
- https://svn.its.yale.edu/repos/shibboleth/yale-shibboleth-installer/trunk (for DEV)
- https://svn.its.yale.edu/repos/shibboleth/yale-shibboleth-installer/tags/Release (for TEST or PROD).
To work on Shibboleth configuration, use Eclipse to check out the current trunk (from the URL listed above for DEV). Edit changes into the file and commit the changes to the trunk. Run the Jenkins DEV install job and test the changes in the development environment. Generally you continue making changes this way until you need to push something into TEST or PROD, which you try to put off until it is necessary.
To install into TEST or PROD, you have to cut a new Release tag. However, you need to save the previous Release tag as your "rollback" if something goes wrong. So use Eclipse SVN Repository exploring to Refactor - Rename the old Release tag to something else. Then use trunk to create a new Release tag.
Request that the Unix Virtualization group run the TEST install job and check the results. When it is time to release, they will run the PROD install job.
If something goes wrong with the new install, rename the /tags/Release to something else for later diagnosis, restore the previous saved tag to the "Release" name, and have the PROD install job rerun.