ID Broker operations manual

Release Process

6. Release Process#

This chapter’s target audience are UCS@school developers and the operators of the ID Broker. It explains how the software of the ID Broker is released, tested and rolled out.

The regular steps during the release process are the following:

  1. Pre-release by the UCS@school Developers

  2. Software artifacts are released by the UCS@school Developers

  3. Rollout on staging environment by the operators of the ID Broker

  4. Product tests on staging environment by the operators of the ID Broker

  5. Rollout on production environment by the operators of the ID Broker

  6. Product tests on production environment by the operators of the ID Broker

If anything of the above failed, please notify UCS@school Developers.

6.1. Pre-release#

The UCS@school developers make sure the software component versions which are scheduled for release are tested and documented. All stakeholders are notified about releases in advance:

  • For changes in the ID Broker SDDB Builder, the Provisioning API or the UCS@school APIs app the operators of the ID Broker need to be informed.

  • For changes in the Self-disclosure API the service providers need to be informed.

  • For changes in the ID Broker UCS@school ID Connector plugin the school authorities need to be informed.

After the pre-release and the release itself are done, rollout and product tests are first done on the staging environment. If everything works as expected, the rollout is done on production environment and the functionality is tested again.

6.2. Rollout#

When new versions of components are released to the App Center by the UCS@school Developers, a rollout can be done.

On the servers of the Provisioning API server and the Self-disclosure API the UCS@school APIs app can be upgraded by running the following command:

$ univention-app upgrade ucsschool-apis

On the server of the ID Broker SDDB Builder, the respective app can be upgraded by running the following command:

$ univention-app upgrade id-broker-sddb-builder

On the servers for the school authorities the UCS@school ID Connector app can be upgraded by running the following command:

$ univention-app upgrade ucsschool-id-connector

On the Primary Directory Node and the the servers for the school authorities the UCS@school Kelvin REST API app can be upgraded by running the following command:

$ univention-app upgrade ucsschool-kelvin-rest-api

The debian packages for the UCS@school APIs plugins for the Provisioning API id-broker-provisioning-api-plugin and the Self-disclosure API id-broker-self-disclosure-api-plugin are released as errata updates in the id-broker scope.

The debian package for the ID Broker ID Connector plugin id-broker-id-connector-plugin is released as a common UCS@school errata update.

6.3. Product tests#

After the upgrade, the following steps need to be done on the test school authorities Traeger1 and Traeger2 to make sure everything works as intended:

  • Create multiple students and teachers who are in schools configured to be synchronized to the ID Broker. They should each be assigned to at least one school class or workgroup. The users should contain users assigned to multiple schools.

  • Check the /var/log/univention/ucsschool-id-connector/queues.log of the UCS@school ID Connector app: You should see in the log that data of of users and groups configured to be synchronized to the ID Broker is synchronized, data of non-configured schools is not.

  • Check the /var/log/univention/ucsschool-apis/http.log of the UCS@school APIs app for errors.

  • Check the /var/log/univention/ucsschool-kelvin-rest-api/http.log of the UCS@school Kelvin REST API app for errors.

  • Check the /var/log/univention/id-broker-sddb-builder/converter_daemon.log of the ID Broker SDDB Builder app for errors.

  • Use the CLI sddb-builder to check the data is replicated to the target database:

    $ univention-app shell id-broker-sddb-builder
$ sddb-builder data show sddb user entry_uuid $ENTRY_UUID_OF_USER
$ sddb-builder data show sddb group entry_uuid $ENTRY_UUID_OF_GROUP

  • Use the test app on the respective school authority to test the Self-disclosure API. The objects should contain all expected schools, groups and users.

Note

The steps described above only cover the minimal working behavior. Depending on the released changes you may have to test more. Refer to the documentation of the new or changed feature, if applicable.

On this page