Hello all,
We are planning to upgrade our new instance for the first time to the new 20.1 release and are looking for a more detailed perspective from anyone who has gone through the process and taken the time to document what actually happens on the day of. Most of the documentation I am finding is pretty light, i.e. get email>go grab a beer>wait for completion notification>test>next environment>etc. I need a little more detail to understand the order of operations and what to expect leading up to the "2 hours" and what happens after the upgrade is complete or what can go wrong and what should I do, etc. Thanks in advance!
Discussion posts and replies are publicly visible
Doing that for 10 years, there is nothing more than that. Testing is mostly some smoke tests.
In my experience it's pretty well automated. There is little to no burden on the end users or even the local system admins, as Appian Cloud support takes care of basically everything. You should make sure users know to be logged out beforehand (the worst that could happen is they lose some work), but otherwise, "go grab a beer" is about the best summary. It usually takes far less long than the time window they give; an email is sent as soon as that environment's upgrade is complete so you know it's time to log in and do some quick testing if you want.
Hi VICTOR TORRES,
Stefan Helzle & have been through this. I largely agree with their sentiments.
I haven't seen the "grab a beer" docs, but I'm a fan.
Nothing should go wrong. The Cloud Team does this for a living, and they do it well. There's a good chance they'll finish early.
I'd add 3 things.
First, as Mike says, treat the window like any other system outage managed by your org. Make sure users understand when the system will be offline. Talk to [Appian application] product owners (POs) ahead of time to verify the the planned outage window won't interfere with critical business operations. Make sure you know your POs. Don't assume you know their schedules. They get used to the way things are, and might plan things without talking to you. Communicate your maintenance window in advance and solicit input from the PO's. It's better to be covered and have superfluous input and feedback than it is to work in a vacuum and be in trouble when you least expect it.
Next, A platform version upgrade is intended to be 100% backwards compatible. You should not experience adverse effects to your application as a result of the upgrade. However, there have been rare occurrences of unexpected behaviors in upgrades observed by early adopters. It is for this reason that it is sometimes desired to test the platform upgrade in a "prod mirror". The UAT instance is often used. This keeps a clean path to production available for the limited testing period. Put your critical apps through some test use cases on the newest version and look for behavior changes. Sometimes these changes will be intentional in the UI. You can have a small group of power users do the testing and have them point our stuff that looks different. Then you can collect that data and ship it back to the PO and explain - "your app works fine, but it looks a little different. consider telling your users."You'll look sharp.Consider the impact to your home life if something goes wrong. Plan ahead accordingly Be sure to test that logical evaluations, i.e. business rules, work as expected (they should). More is better. Then you're ready for prod.
Finally - Upgrade backwards: starting optionally with a test box if you have one, followed by PROD, then QA, then DEV.The Cloud Team will not stop you from upgrading in an order that derails your delivery path to production. They just don't have that insight into how you use your environments.I wouldn't have thought I had to go through this, but it came up with a customer last week.You cannot move code from an appian instance on a later version to an instance on an older version. e.g. An application exported from 20.1 will not import on 19.4 or 19.3, etc. However, 19.3 code will import fine to 20.1.If you upgrade Dev before QA, you cannot move new code to QA. if you upgrade QA before Prod, you cannot move tested code to Prod.Often, seasoned pros will upgrade Prod after some testing on a "parallel path" (like a UAT box), but save dev and QA for a few days, and then upgrade those 2 together.
Bottoms Up!