...
...
...
...
...
...
...
...
...
...
...
...
...
1. Overview
As a Bitcoin ATM operator, you want to maximize your fleet’s uptime, even when performing necessary upgrades and maintenance. This article will help you to adopt the best practices in the area of upgrading your server and terminal network with minimum down time downtime and the other risks that might be involved.
...
...
| Table of Contents |
|---|
...
2. Understand release versioning and frequency
Naming
Our product comes with major releases and minor releases. Minor releases are also called patch releases.
| Info |
|---|
Naming convention |
...
: yyyymmdd.pp example 20231012.20. Where 20231012 is a major version and .20 is a patch level. |
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 design designed to be safe and easy for the operators to install. Patch releases are numbered in incremental order.
Release
...
frequency
GENERAL BYTES releases typically publishes a new major release once a every month in average. Patch releases frequency depends on number of bugs discovered.
Staying on supported version
GENERAL BYTES maintains only last two major releases meaning that only last two major releases receive patch releases. Unsupported major releases are Between these major releases, GB will publish patches whenever bugs are discovered. These are called minor, point, or patch releases.
3. Stay supported by GB
GENERAL BYTES actively maintains the current release and the prior release, meaning that only these latest two releases receive patches and are considered as supported versions. Releases older than these two get marked as EOL(End Of Life) on the patch releases page and they become unsupported.
It is highly recommended to always have run your production running server on a supported release. Risks involving 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 is able to can provide a fix for in such situations via a new patch release , but only on for currently supported releases.
...
4. Right time for upgrading production
Please time your upgrades to coincide with periods of maximum available GB support
Don’t upgrade your operation to a release that has not been publicly released publicly or has been announced yesterday. It may contain bugs. Let other operators to discover them if you don’t need to upgrade ASAP.
Don’t upgrade on a Friday or Weekends. a Weekend. If you hit an issue, GB development and QA departments are not available on weekends when you hit the issue and . Any new patch release needs to won’t be released before the next working day.
Don’t upgrade on a Monday. GB development and QA departments is likely to have limited resources on Monday due to team meetings and accumulated issues that has been identified over the past weekend and need to be addressed with 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 from 18th of Dec to 3rd of January when GB has limited resources due to Christmas season.
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.
Do follow the patch releases page to know when a new patch version is released.
Do let other operators discover bugs first (and GB fix them) if you don’t need to upgrade ASAP.
5. Upgrade Pillars
GB has perfected the following pillars over the years on how operators should evaluate and install new releases with minimum . Performing upgrades on these pillars will minimize the risk of negative impact on their operation with upgrade. Following procedure is recommended at least for operators that have 100+ machines but smaller operator may adopt this procedure too.impacts of any upgrade to your operation. Upgrade pillars are essential to the largest operators that have fleets of 200 or more machines. They are also highly recommended for operators with smaller fleets.
Pillar I: Establish environments if not present already
...
| Note |
|---|
Do not share |
...
databases between any of |
...
these environments. |
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.
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.
You may skip the creation of this environment if you don’t
plan on creating extensions for your server.
This environment is typically used by developers testing their extensions.
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.
This is the environment where you install the new release first.
Here you get familiar with new features and make sure that the product operates correctly in your scenario with your configuration.
Make sure the API keys for wallets are different than production.
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.
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.
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;
Don’t give access to this server to anyone who doesn’t already have access to your production server as it contains valuable data.
Pillar II: Upgrade Laws
...
Always 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…
Pillar III: The Upgrade Flow
...
Test new release on testing environment
Evaluate new features.
Make sure essential features work.
Perform test transactions on your machine.
Test that your extensions are compatible with this release and are working as expected.
When something seems to be broken contact GB tech support to fix the issue with patch release.
When everything works go to step 2.
Test upgrade on your pre-production environment.
Perform test transactions on your machine.
Perform upgrade and take notes of the steps you had to make and values you filled in.
Make sure essential features work and perform quickly - spot possible performance issues when listing terminals or identities.
When something seems to be broken contact GB tech support to fix the issue with patch release.
When everything works go to step 3.
Upgrade production environment
Choose a good date for your upgrade.
When your downtime will have minimum impact on your customers.
Not far from your previous pre-production upgrade so you remember well what steps you took and workarounds has been taken.
Use the notes from your dry-run on pre-production environment.
Follow upgrade laws
...
6. How new release gets manufactured
Any change to our software is associated with a development ticket containing description of a change and desired new behavior may it be a new feature or bug fix.
Every developer who implements the function tests the function himself and describes how feature should be tested.
Every change made by a developer undergoes peer review and automated tests before is merged into the product making sure that only quality, secure, standard-following, non-breaking code makes it into the product. At GB we develop new features into the main branch.
Every month we take what is in the main branch and create a new major release with patch level 1 and create Changelog draft. Every release undergoes automated testing involving multiple terminals running in emulators testing various configurations.
GB’s quality assurance(QA) department is testing every new change to the code ticket by ticket. Whenever QA decides that feature or bugfix needs improvement it is returned to the developer.
QA department is testing also not changed functionality making sure that essential functionality is not impacted.
Any correction to tested release results in production of new patch release that gets tested again.
Once testing is nearing competition (few tickets need to be tested) our Support department reviews Changelog draft and selects candidates for QA department. Candidates represent functionality that deserves to be documented as KB article. QA creates draft of the KB articles.
Support department reviews KB articles and improves the wording and structure making sure articles are easy to read, straight forward, unambiguous and quickly understood.
Once release has only a few bugs to be resolved it is deployed into GB’s beta environment representing small(15 terminals) ATM operation in Prague, Czech Republic. During this period the release is tested by real end-customers in real operation when additional issues are discovered and fixed.
When there are all issues resolved major release is introduced to all of the operators via Telegram channel and Changelog page.
Small operators tend to adopt new releases sooner than larger operators and discover additional bugs that get fixed in subsequent patch releases.
Publicly available supported major releases continue to receive the patch releases for their entire life until marked as and of life.
...