Scheduling an Update
Dual Code offers its clients zero-touch updates. Zero-touch updates mean that when a software release becomes available, clients do not need to schedule the update of their servers.
Our release process requires the successful execution of over 22,000 automated tests against all areas of our software before an update becomes generally available. And that's not all! Dual Code then further verifies each and every client installation by applying the update to a copy of their live environment and then running a complete system health check against that copy. The results are displayed in a System Health report available in your system. Any reported failure will be manually inspected by one of our application specialists. When no failures are reported, the system will automatically schedule the update of both your live and staging servers and notify all System Administrators.
The production and staging servers are scheduled to get updated at the same time since you are not required to review and/or approve the updates. This eliminates pain points for organizations as well as delays in the installation of the update, and in turn reduces your exposure to cyber attacks. Organizations who prefer to assign resources to manually verify the update on their staging server prior to updating their live environment can do so by leveraging a scheduling tool built in the learning environment to re-schedule the date and time of the update for either system (e.g. staging or production).
PLEASE READ
Even though Dual Code offers zero-touch updates, we still recommend that you read the release notes when they become available and PRIOR to the update taking place. If you have any concerns with any items in the release notes, we recommend that you review them on your staging server before updating your production server. Alternatively, you may contact us via our Help Desk to learn more about these changes.
Frequently Asked Questions
Q. Who gets informed when an update is scheduled?
A. All users who are assigned the role of System Administrator get notified when an update is scheduled. They receive an email (using the email address they have on file in the learning environment) and a notification in the learning environment using the system's built-in notification tool.
Q. What happens if the person who is normally emailed is away for an extended period of time (e.g. on vacation, on leave)?
A. It is your responsibility to make sure you have coverage if the person normally in charge of the updates is away. Even if it's for a short period of time (e.g. a sick day). If your System Administrators fail to reschedule / cancel the update, the staging and production servers will be updated as per the schedule, and downtime will occur. Dual Code will not be held responsible if your System Administrators fail to reschedule / cancel the update of your servers, even if they were away for an extended period of time.
Q. How long does an update take (e.g. how much downtime)?
A. Generally speaking, updates require less than 30 minutes of downtime, but the actual time varies based on the size of your system. When you get notified that the update is starting, the approximate time it will take to complete the update (the downtime) is specified in the email itself. If you want to know ahead of time how long the update is expected to take, you can see it on the System Health page.
Log in the system in question as a System Administrator
Go to Site Administration > Reports > System Health
Click on the "Review" button next to the "Update" check
Q. Can I reschedule an update?
A. Yes. System Administrators may reschedule an update. This can be valuable if you plan on reviewing the changes on your staging server before they get applied to your production server, or if you want to delay the update of the servers because you anticipate a lot of traffic at that specific time and do not want the system to become available.
Log in the system as a System Administrator
If you want to reschedule the update to the production server, you would log in the production server
If you want to reschedule the update to the staging serve, you would log in the staging server.
Go to Site Administration > Reports > System Health
Click on the "Review" button next to the "Update" check
Click on the 'Reschedule" button
Select a date / time for the update from the available time slots
Note that you can reschedule the date/time for the production system, staging system, or both systems from the production environment. (When viewing the System Health page on the staging server, you are only able to reschedule the staging server update.)
Q. I find myself always rescheduling updates. Can I simply change our default update schedule?
A. Yes. As a System Administrator, you can set a preferred day of the week and time for your schedule. You can also specify how much lead time you would like, which indicates the minimum time interval between when an update becomes available and when it is applied to your system.
Log in the system in question as a System Administrator
Go to Site Administration > System Configuration
Go to the “System maintenance and updates” section of the page
Make the required changes and save the page
Q. Can I cancel an update?
A. It depends. You may cancel your update, unless:
The update is mandatory (e.g. it contains high-priority security fixes that put you at risk of a cyber attack)
You are no more than 2 releases behind. For example, if you are running 4.1.9, you can skip 4.1.10 and 4.1.11 but cannot skip 4.1.12.
Q. What if I want to test the update on our staging server before our production server is updated?
A. System Administrators have the ability to reschedule and in some cases, cancel the upgrade of their servers. If you want to test the update on staging before it gets applied to your production server, we recommend that you accelerate the update of your staging server and/or delay the update of your production server. For example, if after reviewing the release notes, your organization feels that it needs a week to properly test the improvements and new features, than you should reschedule the updates of the staging and production servers to make sure they are at least one week apart.
If your tests are taking longer than anticipated, you can continue to reschedule (delay) the update of your production server
If your tests went well, you can reschedule (accelerate) the update of your production server.
Note that you can't reschedule / cancel at the last minute. In other words, if on the day prior to your upgrade, you feel that you need more time to verify certain features, you should reschedule the update as soon as you know. The scheduling tool will not allow you to reschedule nor cancel an update at the very last minute.
Q. What if I can't wait for the regular / automated update and need to request an urgent update to our system?
A. You can schedule an update of your system via the System Health report.
Log in the system in question as a System Administrator
Go to Site Administration > Reports > System Health
Click on the "Review" button next to the "Update" check
Q. How do I know which release is on our system?
A. The "Update" check in the System Health report references the version of the software you have (e.g. 4.1.11.3) and the "Build" number (e.g. 20240610). The build number is a date in the YYYYMMDD format. It tells you exactly on what day the release installed on your software was released.
Q. How do I know which release will be installed?
A. The release you will get is the build available 1 day before your scheduled update. So if you are scheduled to be updated on March 31st, you would get the the latest build available on March 30th. It's important to understand that this is true regardless of when you schedule the update of your staging server. For example, if you schedule your staging server to be updated on February 28 and then schedule the update of the production server for March 31st, on March 31st, both the production server and the staging server will be updated to the release available on March 30th. The process does not allow to install any release other than the latest release on your production server.