Automatic Updates

Fieldpine systems will automatically update their version from central Fieldpine servers. As retail systems are often business critical and no update can be completely without risk, there are a number of options and controls you can define to how different lanes might update. This means you can update some lanes sooner than most lanes, so that any potential issues can be trapped on known beta lanes first.

You do not need to define anything with automatic updates if you don't want too, if left alone the system will try and self determine what it thinks is the best approach.

Concepts

Code updates are released in groups, where the code has to prove itself at the each level before it moves to the next level, although this "proving" can be brief in some circumstances. The development pipeline used by Fieldpine is conceptually as follows

Developer changes source code	--» Compiles & Builds	--»	Whitehot release
Code is approved by developer	--» Release kit created.	--»	Development release
Automated testing systems verify code integrity	--» Release kit published.	--»	Latest release
Feedback from early adopter sites and other approval steps		--»	Stable release
Some versions selected as long term releases		--»	Previous Generation release

As a retailer, you will be on the stable release, unless you opt in to the latest release, or in advanced situations the development release.

Once a release group is selected and a program decides it should update, then another option called the Canary Level is checked. The canary level is an indication of how early you would like this lane to update relative to your other lanes. If there was no canary level, then all your lanes on the same release group would update at pretty much the same time. By setting some lanes with a higher canary level, we will try to update those lanes first, so that should issues arise due to the update it is in a controlled location, or in stores that are more technically relaxed.

How fast is the deployment pipeline?

When the "latest" release kit is created it is internally tagged with some controls that indicate our internal level of confidence. Sometimes changes are incredibly minor, or tightly targeted to specific retail configurations, in which case the whole deployment pipeline is relatively compressed and updates could flow from "latest" to "stable" and through your canary levels in a small number of hours.

A more normal release will typically delay for 2 or 3 days in "latest" before switching to "stable". It may then take another 2 or 3 days to work through your canary levels. However, even within the stable release, Fieldpine do not update all retailers at once and stagger across retailers as well.

Fieldpine support have the ability to override your controls in limited circumstances.

How do I stop releases?

In the profile setup you can set a "block updates until" date. So if you are wanting to pause for some reason, enter the date when the update should pause until.

Fieldpine will also apply mini change freezes ourselves to some retailers without your knowledge. Such as

• Christmas and New Year
• Common stocktake and year end events
• Fridays. We do not typically update retailers using the stable release on Friday or Saturday. This is due to staff changeover and also the availability of technical support staff.

---

Typical and Recommended Configuration Options

Single Store, Single Lane Retailers

As a single lane retailer there obviously isn't the option to update lanes in different orders. We suggest you leave the configuration on "Stable", or perhaps "Latest" if you are more technically savvy.

Multi Store, Multi Lane Retailers

When you have multiple lanes and stores available, we recommend the following

Either, Choose a subset of lanes to run the "Latest" code. This will ensure you receive code updates as soon as possible, which gives the maximum amount of time before kits progress to stable.

Or, set the canary level to be aggresive on a subset of lanes. These lanes will typically update before the main block. This approach does not offer as much time before code is generally delivered to all lanes, so stores and lanes need to be reactive in reporting issues.

---

Testing Updates to Fieldpine or the Computer

If using PosGreen on Windows

1. Start PosGreen as normal and verify no difference to normal startup
2. If the update is to AntiVirus, generally any issues will completely stop operation at this point if there are issues
3. Enter the quickcode "123" (local status report) and also "F123" (internet status report) and ensure they work. The F123 is especially important as if it fails then Fieldpine support tools may not be able to operate.
4. Perform a simple sale and verify no issues
5. Print a receipt and verify it prints.
6. Perform sales to cover your typical buiness transactions. If you have custom logic or advanced business rules perform sales to cover the majority of them. It isn't generally practical to exhaustively test every combination, so the intent is to cover as much of the common logic as practical
7. If using integrated eftpos, perform a test sale. If the update is to Fieldpine this may not be required as changes to Eftpos interfaces are rare and documented
8. If you have specialised hardware, such as scales, scanners, fuel controllers, run transactions to exercise each of these.
9. Verify all sales are flowing to your store servers and head office servers.

If using Fieldpine Online or Web Browser Interfaces

1. Visit the web page https://fieldpine.com/support/roadmap/browsertest.htm and verify tests are all green
2. If you have serial barcode scanners (uncommon), test these to verify operation. This is a less used code path in Browsers so will not always be tested by the masses.
3. Verify receipts can still be printed
4. Perform sales tests as details in "PosGreen on Windows" to satisfy yourself