Deployed 321a437 with MkDocs version: 1.4.2

changelog/index.html

@@ -1129,6 +1129,7 @@ <h3 id="main-branch-no-tagrelease">main branch (no tag/release)</h3>
 </ul>
 <h3 id="documentation">Documentation</h3>
 <ul>
+<li>July 16, 2024: Added "<a href="/islandora_workbench_docs/workflows/#cross-environment-deployment-continuous-integration">Cross-environment deployment / Continuous Integration</a>".</li>
 <li>July 14, 2024: Added docs on the new <code>protected_vocabularies</code> config setting to "<a href="/islandora_workbench_docs/fields/#taxonomy-reference-fields">Taxonomy reference fields</a>" and removed some cruft; added docs on "<a href="/islandora_workbench_docs/preparing_data/#encoding-of-text-files">Encoding of text files</a>".</li>
 <li>July 9, 2024: Added "<a href="/islandora_workbench_docs/fields/#using-numbers-as-term-names">Using numbers as term names</a>".</li>
 <li>July 7, 2024: Added "<a href="https://mjordan.github.io/islandora_workbench_docs/preparing_data/#using-a-local-or-remote-zip-archive-as-input-data">Using a local or remote .zip archive as input data</a>".</li>

workflows/index.html

@@ -1291,7 +1291,7 @@ <h3 id="sharing-configuration-files-with-other-applications">Sharing configurati
 </code></pre>
 <p>It's probably a good idea to namespace your custom/non-Workbench config entries so they are easy to identify and to reduce the chance they conflict with Workbench config settings, but it's not necessary to do so.</p>
 <h3 id="cross-environment-deployment-continuous-integration">Cross-environment deployment / Continuous Integration</h3>
-<p>Workbench can be used to create the same content across different development or testing environments. One application of this is to allow a team of developers can be sure they are all using the same Islandora content. For example, it is possible to commit one or more Workbench config files to a shared Git repository, and when a developer rebuilds their envrionment, automatically run Workbench using those configuration files to load the shared content.</p>
+<p>Workbench can be used to create the same content across different development, testing, and deployment environments. One application of this is to allow a team of developers can be sure they are all using the same Islandora content. For example, it is possible to commit one or more Workbench config files to a shared Git repository, and when a developer rebuilds their envrionment, automatically run Workbench using those configuration files to load the shared content.</p>
 <p>Some tips on making Islandora more "portable" across environments include:</p>
 <ul>
 <li>Adding the Workbench user's password to an <a href="/islandora_workbench_docs/installation/#password-management">envrionment variable</a>, eliminating the need to include the password in the configuration file</li>
@@ -1300,6 +1300,7 @@ <h3 id="cross-environment-deployment-continuous-integration">Cross-environment d
 </ul>
 <p>The same capabilities apply to using Workbench to load data for automated testing during Continuous Integration workflows and configurations.</p>
 <p>An interesting facet of using the combination of remote Zip and (optionally) a Google Sheet as input is that people other than developers, such as content managers or testers, can add content to ingest without having to commit to the Git repository. All they need to do is update the Googl Sheet and Zip file. As long as the URLs of these inputs do not change, the next time the developers run Workbench, the new content will be ingested.</p>
+<p>Finally, automatically populating staging and production environments on build is a useful way to test that these environments have deployed successfully. Running a <a href="/islandora_workbench_docs/rolling_back/">rollback</a> task can then delete the sample content once deployment has been confirmed.</p>
 <h3 id="case-study">Case study</h3>
 <p>Simon Fraser University Library uses Islandora Workbench to automate the transfer of theses from its locally developed thesis registration application (called, unsurprisingly, the <a href="https://theses.lib.sfu.ca">Thesis Registration System</a>, or TRS) to <a href="https://summit.sfu.ca">Summit</a>, the SFU institutional research repository running Islandora. This transfer happens through a series of scheduled tasks that run every evening.</p>
 <p>This diagram depicts the automated workflow, with an explanation of each step below the diagram. This case study is an example of the "<a href="/islandora_workbench_docs/workflows/#integrations-with-other-systems">Integration with other systems</a>" workflow described above.</p>