Summary

This article will help you to adopt the best practices in the area of upgrading your server and terminal network with minimum downtime and the other risks that might be involved.

...

Our product comes with major releases and minor releases. Minor releases are also called patch releases.

Major releases contain predominantly new functionality, database, architectural, and security improvements and may contain changes that introduce bugs.

Minor releases contain just bug fixes and are designed to be safe and easy for the operators to install. Patch releases are numbered in incremental order.

...

GENERAL BYTES typically publishes , on average, a new major release every month. Between these major releases, GB will publish patches whenever bugs are discovered. These are called minor, point, or patch releases.

Stay on a currently supported version

GENERAL BYTES actively maintains the current release and previous the prior release, meaning that only these latest two major releases ever receive patch releases. The previous major release is then patches. Releases older than these two get marked as EOL(End Of Life) on the patch releases page and becomes they become unsupported.

It is highly recommended to always run your production server on a supported release. Risks arising from not staying on a supported version include; but are not limited to, sudden downtime due to 3rd party wallet provider API change or 0-day vulnerability discovery. GENERAL BYTES can provide a fix in such situations via a new patch, but only for currently supported releases.

Dos and Don’ts: timing

...

Please time your upgrades to coincide with periods of maximum available GB support

• Do follow the patch releases page to know when a new version is released.

• Don’t upgrade your operation to a release that has not been publicly released. It may contain bugs.

• Do let other operators discover them first (and us fix them) if you don’t need to upgrade ASAP.

• Don’t upgrade on a Friday or a Weekend. If you hit an issue, GB development and QA departments are not available on weekends. Any new patch release won’t be released before the next working day.

• Don’t upgrade on a Monday. GB development and QA departments are frequently busy with team meetings or are responding to issues that arose over the weekend. Limited resources must be delegated amongst several items competing for priority.

• Don’t upgrade on US and Czech business holidays.

• Don’t upgrade over Christmas. The last two weeks of the year and the first days of the new year (December 18th to January 3rd) are when most GB employees partake in family-oriented vacations. The office is a ghost town.

...

Three maxims for upgrading

GB has perfected the following three (3) maxims over the years following procedure on how operators should evaluate and install new releases with minimum . These are 3 maxims that will minimize the risk of negative impact on their operation with upgrade. Following procedure is recommended at least for impacts of any upgrade to your operation. These 3 maxims are essential to the largest operators that have fleets of 100 + machines but smaller operator may adopt this procedure too.or more machines. They are also highly recommended for operators with smaller fleets.

Maxim I: Establish environments if not present already

...

...

...

1. Production environment. Good The good news, you don’t have to create this environment as it probably already probably exists. This is where you your business operation is happening. This is where your revenue is generated and where all sensitive information resides.

2. Development/Sandbox environment. Optional. Install this server with a different license key that than the one your production is using and connect one of the machines to it.

   1. You may skip the creation of this environment if you don’t

   have developers

   1. plan on creating extensions for your server.

   2. This environment is typically used by developers testing their extensions.

3. Testing environment. Install this server with a different license key that than the one your production is using, and connect one of the machines to it.

   1. This is the environment where you install the new release first.

   2. Here you get familiar with new features and make sure that the product operates correctly in your scenario with your configuration.

   3. Make sure the API keys for wallets are different than production.

4. Pre-production environment. This Created this environment is created by cloning your production environmentone. This server shares the licensing key with your production server. Connect one of the machines to it.

   1. Make Be sure that you clone also the database and not share it isn’t shared with your production environment. Otherwise, you can destroy risk destroying your production database.

   2. Make sure that you DISABLE publishing to HQ on the pre-production server publishing to HQ as . Otherwise, it will otherwise report to coinatmradar.com that all of your terminals are offline. This can be achieved by running the following statement in the pre-production database:

      Code Block
      language sql
      UPDATE terminalpublishsettings SET publishtohq = 0;

   3. Don’t give access to this server to anyone who doesn’t already have access to your production server as it contains valuable data.

Maxim II: Upgrade Laws

...

• SERVER FIRST always upgrade the server first, and then upgrade the terminals. Major releases may not be compatible with previous major release. Terminals with older release installed may not respond to commands sent from newer server.

• Do not NO DOWNGRADES Don’t rollback the server installations version or database version. Installing a new server version includes database table structure changes that are not aren’t always compatible with previous server versionversions. Just don’t do it.

• SKIPPING OK It is usually OK to skip versions forward. You don’t need to install every release we make. Just install our latest release and our the software will perform the necessary changes that were introduced in from previous releases such as database structure changes.

• DO TERMINALS IN BATCHES Upgrade your network in batches. After each batch evaluate that upgraded machines work correctly. First upgrade Batch growth explained: If 1 machine upgrade is a success, then do 20, then 50, then 100, then 500, then 1000, then 2000…

...