Plan your installation or upgrade setup, hardware and software requirements and so on before you begin..
Before you plan your installation or upgrade, let us understand TeamForge and its services.
TeamForge site consists of a core TeamForge application and several tightly integrated services that support it. In addition, you can integrate TeamForge with other third party applications such as Nexus, Jenkins, Jira and so on. Some of the TeamForge services are mandator and some are optional. You can install the services, all in one single server, or distribute them across two or more servers.
The names of some of the TeamForge services have been renamed in TeamForge 17.1. In addition, the site-options.conf syntaxes for defining the TeamForge services running on a host (host:SERVICES token) and TeamForge domain name (host:PUBLIC_FQDN token) have been changed in TeamForge 17.1.
Unless otherwise notified, to ensure backward compatibility, TeamForge 17.1 and later versions support both old and new syntaxes for defining your host and domain tokens. Similarly, TeamForge 17.8 supports both old and new service names. However, it is recommended to adjust your site-options.conf in line with these changes as support for older syntax and naming convention would be dropped in due course.
Here's a list of available TeamForge services.
| Services | Mandatory/Optional | Old Name | Description |
|---|---|---|---|
| ctfcore | Mandatory | app | Main TeamForge application server |
| search | Mandatory | indexer | Indexing and Searching |
| Mandatory | NA | Email server | |
| ctfcore-database | Mandatory | database | Operational database |
| codesearch | Mandatory | codesearch | Code Search |
| etl | Optional | etl | ETL for Datamart |
| ctfcore-datamart | Mandatory if and only if you install etl | datamart | Datamart database |
| subversion | Optional | subversion | SVN Version Control |
| cvs | Optional | cvs | CVS Version Control |
| gerrit | Optional | gerrit | Git/Gerrit Version Control |
| gerrit-database | Mandatory if and if only if you install gerrit | NA | Database for Git/Gerrit. In a distributed setup, add this identifier on the server where you want to run Gerrit database. |
| gerrit-database-performance | Automatically installed if you install gerrit | NA | It is a second database that Gerrit uses to cache data. |
| binary | Optional | Optional | Artifact repository integration |
| binary-database | Mandatory if and only if you install binary | binary | Database for artifact repository integration. Binary app (binary) and database (binary-database) have to installed on the same server. |
| reviewboard | Optional | reviewboard | Review Board code review tool |
| reviewboard-database | Mandatory if and only if you install reviewboard | NA | Database for Review Board. In a distribute setup, add this identifier on the server where you want to run Review Board database. |
| reviewboard-adapter | Mandatory if and only if you install reviewboard | NA | Adapter for Review Board. In a distribute setup, reviewboard-adapter must always be installed on the TeamForge Application Server. |
| eventq | Mandatory | NA | EventQ application server. In a distributed setup, add this identifier on the server where you want to run EventQ application. |
| redis | Mandatory | NA | EventQ in-memory database/data structure server. In a distributed setup, add this identifier on the server where you want to run EventQ application. |
| mongodb | Mandatory | NA | EventQ database server. In a distributed setup, add this identifier on the server where you want to run EventQ database. |
| rabbimq | Mandatory | NA | EventQ AMQP message server. In a distributed setup, add this identifier on the server where you want to run EventQ message queue. |
If you are installing TeamForge, are you planning to install on a single server or distribute TeamForge services across two or more servers? How are you going to distribute the services?
In the default setup, all services run on the same server as the main TeamForge application. But in practice, only the TeamForge application needs to run on the TeamForge application server. The other services can share that server or run on other servers, in almost any combination.
Assess your own site’s particular use patterns and resources to decide how to distribute your services, if at all. For example, if you anticipate heavy use of your site, you will want to consider running the site database, the source control service, or the reporting engine on separate hardware to help balance the load.
When you distribute your services on multiple servers, you must do some configuration to handle communication among the services. Verify your basic networking setup. See Set up Networking for TeamForge.
PostgreSQL 9.6.3 is installed automatically when you install TeamForge 17.8. If you intend to use Oracle, CollabNet recommends that you let the installer run its course, make sure things work normally, and then set up your Oracle database and switch over to it.
The efficiency of your database can have an impact on your users' perception of the site's usability. If your site uses a PostgreSQL database (which is the default), you may want to consider tuning it to fit your specific circumstances. The default settings are intended for a small-to-medium site running on a single server. See What are the right PostgreSQL settings for my site? for recommendations from CollabNet's performance team on optimizing PostgreSQL for different conditions.
TeamForge supports integration with a wide array of third party applications such as Review Board, Git, Nexus, Jira and so on. As a customer you may or may not always want (or have) all of TeamForge's supported integrated applications. It's also quite possible that some of the integrated applications may not always run on all the platforms supported by TeamForge.
To accommodate a wider audience, by default, TeamForge install and upgrade instructions include steps to integrate such third party applications with TeamForge. However, use your discretion to ignore and skip such steps if they are not relevant to your site. See TeamForge installation requirements to understand what it takes to run TeamForge 17.8 with integrations.
Though the TeamForge17.8 installer supports one-hop upgrade from TeamForge 16.3 or later versions, TeamForge 17.8 upgrade instructions, in general, are for upgrading from TeamForge 17.4 (including update releases, if any) to TeamForge17.8.
During an upgrade, the TeamForge 17.8 migration script detects the TeamForge version you run, checks if it's TeamForge 16.3 or later, and if 'true', proceeds with the data migration.
The migration script aborts with an error message if it detects TeamForge 7.2 or earlier versions. You must upgrade your site to TeamForge 16.3 or later and then upgrade to TeamForge 17.8.
If you aren't the person who first installed your current TeamForge site (or maybe, even if you are), it's essential to catalog the hosts where your services are running and to know what configuration has been applied to them.
While upgrading to a latest TeamForge version, you can shoose to upgrade on the same hardware or on new hardware. In general, it is good to have a backup plan in place. Same hardware upgrades need no backup. However, it’s recommended to take a back up as a measure of caution. See Backup and Restore TeamForge and EventQ for more information.
The post-install.py script is no longer available. It's not required to run the post-install.py script during TeamForge install/upgrade as its functions have been moved into /opt/collabnet/teamforge/bin/teamforge script's "deploy", "migrate", "bootstrap" and "initialize" hooks.
A new service, gerrit-database-performance, has been added in TeamForge 17.8-Git integration. This is installed by default with the gerrit-database. It is a second database that gerrit used to cache certain data for better database performance.
The teamforge script now takes care of switching SELinux to "permissive" mode during install or upgrade and switches back to its original mode once the install or upgrade is complete.
TeamForge implements SELinux policies for most of its services such as JBoss, Apache, ETL, Tomcat and so on. However, you can revert these policies (not recommended), if required. For more information, see TeamForge SELinux policies.
SMTP authentication has been enabled for relays and as a result the JAMES_ACCESPTED_RELAYS token is no longer supported. Remove this token from the site-options.conf file while upgrading to TeamForge 17.8.
Reset the PASSWORD_CONTROL_EFFECTIVE_DATE token. If not reset, the Password Control Kit (PCK) disables, deletes or expires user accounts immediately. You must pick a future date and set it to this token. For example, you can use the following logic and pick a future date: PASSWORD_CONTROL_EFFECTIVE_DATE=<the day on which TeamForge upgrade is done> + PASSWORD_WARNING_PERIOD.
You cannot use an IP address in the host:SERVICES token (such as 1.2.3.4:SERVICES=). teamforge provision fails if an IP address is used.