Migration process

1. Version compatibility

Table 1. Version Compatibility (sorted by delivery dates)

Team for Capella

(based on) Capella

(third party software) Sirius

1.0.3 (32bits & 64bits)

1.0.3

Sirius 3.1.6

1.1.4 (32bits & 64bits)

1.1.4

Sirius 4.1.9

1.2.2 (64bits)

1.2.2

Sirius 5.1.4

1.3.2 (64bits)

1.3.2

Sirius 6.1.4

1.4.0 (64bits)

1.4.0

Sirius 6.3.0

1.4.1 (64bits)

1.4.1

Sirius 6.3.1

1.4.2 (64bits)

1.4.2

Sirius 6.3.3

5.0.0 (64bits)

5.0.0

Sirius 6.4.0

5.1.0 (64bits)

5.1.0

Sirius 6.5.0

5.2.0 (64bits)

5.2.0

Sirius 6.6.0

6.0.0 (64bits)

6.0.0

Sirius 7.0,1

6.1.0 (64bits)

6.1.0

Sirius 7.1.0

7.0.0 (64bits)

7.0.0

Sirius 7.4.1

7.0.1 (64bits)

7.0.1

Sirius 7.4.5

7.0.1_202509 (64bits)

7.0.1

Sirius 7.4.5

7.0.1_202601 (64bits)

7.0.1

Sirius 7.4.5

7.0.1_202607 (64bits)

7.0.1

Sirius 7.4.5

7.1.0 (64bits)

7.1.0

Sirius 7.4.5

2. Model migration from previous version to v7.1.0

The CDO Framework cannot handle multiple version of the same metamodel on the same repository. Capella projects of different Capella versions needs to be exported on separate repositories”.

To use a previous version model in Team for Capella v7.1.0, a migration must be done to be compliant with the new metamodel and file extensions.

This model migration is provided by Capella and must be done between each minor version (from v1.4.x to v5.x, for example).

The process to migrate a model to v7.1.0 from a shared repository follows the following steps:

  1. If Team for Capella users have created local diagrams (i.e.: diagrams stored in the local .aird file), they have to move all diagrams they want to keep to a remote .aird or .airdfragment (“Move Diagrams” action),

  1. Import locally the model to migrate (“Import… / Team for Capella / Import model from remote repository”) using previous version (v5.x) of Team for Capella. Make sure that the associated team server is running before importing from remote repository. Another way is to use the last valid import of the Scheduler.

    → Make a baseline of the imported model,

  1. Migrate the previously imported model (“Migrate Project toward current version”) in a Team for Capella v7.1.0. (The migration can also be done in Capella v7.1.0).To do so, please refer to Migration dedicated chapter of Capella online installation guide,

    → Make a baseline of the migrated model,

  1. Export the migrated model to the Team for Capella server v7.1.0 (“Export… / Team for Capella / Capella Project to Remote”) using Team for Capella v7.1.0. Make sure that associated team server is running before exporting to remote repository.

After performing these steps, the model in the shared repository is in right version.Team for Capella has to be upgraded on client’s computers.Then users can connect and work on the model.They do not need to do any migration.

3. Capella Addon migration

Some Capella addons extend the Capella metamodel with new metaclasses. Installing a new version of an addon may introduce a different version of the metamodel extension that alters existing metaclasses. In that case, a migration will be needed, Capella projects using these addons will need to be exported to a new repository. Therefore, the same procedure as the previous part is needed.

4. Model migration from an older version

The model migration is necessary between each version considering only minor and major version change.

  • For the first model migration, you need to reproduce only steps 1, 2 and 3 described above.

  • For the following intermediary model migrations, you need to reproduce only step 3.

  • For the last model migration, you need to reproduce only steps 3 and 4

For example, you start from v1.4.2 model

  • do steps 1, 2 and 3 with previous version = 1.3.2 and new version = 1.4.2,

  • do step 3 with previous version = 1.4.2 and new version = 5.2.0

  • do step 3 with previous version = 5.2.0 and new version = 6.1.0

  • do steps 3 and 4 with new version = 7.0.0.

5. Changes for Server Installation from v7.0.1_202607 to v7.1.0

5.1. Default connection changes

Team for Capella v7.1.0 uses WSS and HTTPS on port 8443 by default. Previous installations commonly used TCP on port 2036 for repository traffic and HTTP on port 8080 for REST administration traffic.

When upgrading:

  1. Keep the cdo-server.xml delivered with v7.1.0 and copy only the required repository definitions from the previous file. Do not restore TCP as the default acceptor.

  2. Provide a PKCS#12 keystore (.p12 or .pfx) whose certificate SAN contains the server FQDN for remote clients and DNS:localhost for the local CLI tools and Jenkins jobs. Configure its path and passphrase in admin-server.properties before the first start.

  3. Keep admin.server.jetty.https.enabled=true, admin.server.jetty.net4j.enabled=true, and port 8443.

  4. Update firewalls and reverse proxies to allow WSS and HTTPS on port 8443. Ports 2036 and 8080 can be closed unless an explicitly restricted unsecured mode is required.

  5. Update remote clients and customized client settings to use the server FQDN, port 8443, and connection type WSS. The delivered CLI tools and Jenkins jobs already use localhost, port 8443, WSS, and HTTPS. For copied or customized jobs and scripts, retain these secure protocol and port settings; if the certificate SAN cannot contain DNS:localhost, replace their repository host and REST httpHost values with the server FQDN.

  6. If the certificate chain is not already trusted, install it in the cacerts store of the Java runtime embedded in each Capella client and in the server-side Capella runtime used by Jenkins jobs.

  7. Test a client connection, an import or export, a database backup, and the server start/stop jobs before reopening the service to users.

For the complete secure setup, see Default secure connections: WSS and HTTPS. For an unsecured compatibility endpoint, see Unsecured connection modes; this configuration is not recommended for production.

6. Changes for Server Installation from v7.0.1_202509 to v7.0.1_202607

  • DB files and dynamic repositories from v7.0.1 or v7.0.1_202509 can be reused in v7.0.1_202607.

7. Changes for Server Installation from v7.0.1 to v7.0.1_202509

7.1. Changes in Server Configuration

  • DB files and dynamic repositories from v7.0.1 can be reused in v7.0.1_202509

  • Repositories with OpenID Connect authentication

    • technicalUsers.properties files must be cleared: password are no more stored in clear text but encrypted with BCrypt.

    • Technical users can now be added/updated/removed without restarting the repository, via the REST api.

  • REST Admin server realm passwords are now encrypted with BCrypt.

    • Secure storage must be cleaned from all Team for Capella keys: fr.obeo.dsl.viewpoint.collab.credentials.*

    • Before launching the server, delete TeamForCapella/server/configuration/fr.obeo.dsl.viewpoint.collab.server.admin/secret.txt

    • Credentials and passphrases can now be injected via environment variables instead of being stored in clear text in multiple configuration files. See available variables in Passing parameter using system property or environment.

7.2. Changes in Jenkins Jobs Installation/Configuration

  • It is possible to do reuse current working jobs after updating the TEAMFORCAPELLA_APP_HOME if the new version has been installed at a different location

8. Changes for Server Installation from v7.0.0 to v7.0.1

8.1. Changes in Server Configuration

Changes in cdoServer.xml

  • The default repository’s data source is now named repoCapella instead of capella to match its repository name, ensure naming consistency and ease readability

8.2. Changes in Jenkins Jobs Installation/Configuration

  • A new option has been added to the Repository - Start job to allow the re-initalization of a repository without having to restart the server nor to access the files.

  • URLs of Jenkins plugins have been replaced in installation scripts in order to avoid redirect errors during installation on Linux.

9. Changes for Server Installation from v6.1 to v7.0.0

9.1. Changes in Server Configuration

Changes in admin-server.properties

  • The property admin.server.api.project.get.impl.config.XMLImportFilePath in v6.1 becomes admin.server.api.project.get.impl.config.importFilePath in v7.0.0

Changes in cdoServer.xml

  • The websocket configuration <acceptor type="ws" listenAddr="YourAcceptorName" /> in v6.1 becomes <acceptor type="ws" name="YourAcceptorName" /> in v7.0.0

9.2. Changes in Jenkins Jobs Installation/Configuration

The recommended Jenkins version is now 2.440.3 LTS for the Team for Capella 7.0.0 and the required plugins list has changed. You can read more about the jenkins installation in section System Administrator Guide > Jenkins Installation of the user manual.

The configuration of the Jenkins jobs installation is no longer directly in the installation script install-TeamForCapellaAppsOnJenkins.bat/install-TeamForCapellaAppsOnJenkins.sh. In v7.0.0, the configuration is now in a separate file install-TeamForCapellaAppsOnJenkins.properties. You can read more about the Jenkins jobs installation in section System Administrator Guide > Jenkins Installation > Install Jenkins plugins and jobs required for Team for Capella of the user manual.

9.3. Changes in Jenkins Jobs

The following jobs have been renamed:

  • License Server - Start in v6.1 becomes License Server - Run in v7.0.0

  • Server - Start in v6.1 becomes Server - Run in v7.0.0

  • Projects - Import in v6.1 becomes Projects - Import - repoCapella in v7.0.0

The following jobs have been added:

A new parameter was added to select the repository for the following jobs:

  • All Repository Jobs

  • All Tools Jobs

  • Projects - Export

9.4. Other Changes

In the importer application:

  • The parameter -XMLImportFilePath in v6.1 becomes -importFilePath in v7.0.0

  • The parameter -archivefolder <folder> in v6.1 is replaced by two parameters -archiveProject true -outputFolder <folder> in v7.0.0