This plan is effective from 15/06/16.
Fewzion Entity – Fewzion Pty Ltd or representatives thereof. Referred to as Fewzion, we, our, or similar.
Fewzion Product – Software and systems provided by Fewzion Pty Ltd. Referred to as Fewzion, software, or similar.
Intended Reader – A potential or current client of Fewzion Pty Ltd. Referred to as Client, you, your, or similar.
To catalyse the planning, establishment and implementation of a mutually beneficial process for delivering our products and updates.
To inform you of the basics of our development and release strategy, and how it relates to your deployment process. Then to present preferred and alternative solutions for your consideration.
To call for your action in advising us of your strategy.
Semi-technical or Technical: IT, QA, Change Management, Executive, etc.
Comments of the Author
An important value of the Fewzion team is that we are constantly improving. We are not satisfied with "good enough". Our modern development process gives us the power to continuously release new features and improvements at a rapid pace.
We strive to release a new version every few weeks, favouring small, controlled, incremental updates rather than huge, complex, interruptive upgrades.
Please consider this Release Management Guide as your point of reference and first step towards continuous, smooth and unobtrusive provision of Fewzion.
The goal is simple: we want you to always have the latest version of Fewzion. Generally speaking, there are 2 ways to achieve this with a product like Fewzion:
|Managed (Cloud)||Self-Hosted (On-Site)|
|Runs on our cloud, which we maintain.||Runs on your hardware, which you maintain.|
|We always run the latest versions and handle any required server configuration.||New versions are made available to you to deploy at your will and some configuration may be necessary.|
|Server testing and integration is on us.||On top of our testing and integration, you may have UAT or other required processes.|
Fewzion as a Managed service is obviously a far less complicated method ofdelivery (for both you and us) as we already use an enterprise-grade workflow of Continuous Integration, Delivery and Deployment for our internal development and testing. The process is smooth and automated, only requiring hands-on for unusual or unexpected cases. Updates are available within minutes, or scheduled to run at a specific time.
Of course, though, we recognise that some clients wish to maintain all their own concerns end-to-end whether by technical constraints or administerial policy.
For example: they may be bound by policy to run any new software through their own internal processes like Security Auditing, User Acceptance Testing and Staging;before it is approved for operation. They may also implement strict Freeze Periods or wish to adhere to a longer or inconsistent upgrade schedule.
A case like this presents 2 challenges in making use of our weekly releases:
- Internal processes can take days or even weeks! A new version every week would demand significant and continuous effort.
- Fewzion releases may be out of sync with their deployment availability, but they don’t want to miss out on new features.
If this sounds familiar, we have solved both these problems (and more) for you! We have created a workflow which allows for any amount of divergence in cycles, and grants you the flexibility to skip any number of releases without missing anything.
- We have created a clear, clean separation between our releaseprocess and your deployment process. We release as our workflow prescribes; weekly at a minimum. You deploy whenever you’re able; You decide the schedule.
- We develop in such a way that any and all changes are cumulative. Even deploying the smallest bugfix will ensure you’re caught up on every preceding version. You’ll never miss out.
The obvious caveat to our delivery of updates to you is that the onus is on you to receive the upgrades. We can’t cherry-pick feature X from a release just for you. Want the latest Fewzion? get the latest Fewzion and everything in between!
We adhere to the tried and true software development process which favours regular, small, incremental changes rather than slow, monolithic, cumbersome reinstallations. We tag each incremental change with a version number in the following format:
These digits represent not just a version increment, but they also can tell you at a glance what may be contained within the update. This table explains the basics:
|MEANING||Substantial new functionality
May require training
May require tech upgrades
|Typical, regular update
May fix non-critical bugs
Cannot wait for next week
No new features
|CYCLE||As required||Weekly - Monthly||Nightly when required|
|RELEASE NOTES||Comprehensive introduction for brand new, large features
Typical documentation as per minor for everything else
|A brief list of Features, Improvement and Bugfixes
May include simple detail (e.g: where to find a new button)
|Listed as Bugfixes in next minor release notes
Where appropriate, affected clients notified immediately
|EXAMPLE||"Manage your work visually using maps!"
"Upgraded database, requiring some manual migration"
|"Added a new option to sort Users by length of employment"
"Modified some buttons on Touch Screens to be bigger"
|"Fixed rare bug where a User could enter an invalid date for a leave request"|
This is known as "Semantic Versioning", as it gives meaning beyond just "this version is newer than the last". So for example when we update Fewzion:
- From 1.5.2 to 1.5.3 (a patch update)
You know we fixed a bug, possibly one you reported to us!
- From 1.5.2 to 1.6.0 (a minor update)
You know this is a typical weekly release with no special attention required.
- From 1.6.0 to 2.0.0 (a major update)
You know this may require attention and to be ready for detailed information.
With this understanding you can easily identify which release you wish to deploy. Depending on your deployment cycle, you may also wish to create rules for different point releases. For example if your deployment is automated, you can rule:
- Do not auto-deploy Major Releases: requires management approval
- Auto-deploy Minor Releases: every Sunday at 23:00
- Auto-deploy Patch Releases: every Tuesday and Thursday at 23:00 (if any)
We Release - You Deploy
This illustration is an abstract yet practical way to visualise a typical cycle of release and deployment. Its purpose is primarily conceptual, so please be aware that your particular strategies may use different or intersecting terminology. Please contact us if you wish to clarify any points.
- We always have a version in active development and a planned version for us to begin next.
- Upon completing development and testing, we package and release the version to our deployment server. We then get straight to work on the next version and yet another version is planned.
- Our deployment server has a few roles and responsibilities:
Holds multiple packaged versions, maintaining their order.
Pushes packages automatically to anyone configured to receive in this way, taking into account their desired frequency and any specified time windows.
For manually triggered deployment, waits for instruction on when to send which package.
- Have ensured that Fewzion has a current and correct release plan for your deployment.
- Have a correctly configured deployment client which our server can target for the release.
Links to the technical details and requirements for this deployment client can be found in the references.
- Using the methods defined in the Release Plan, the package containing your required version will be deployed via the deployment client, and our integration procedure will ensure successful installation and initialisation.
In some cases (e.g: Major release requiring manual configuration) there may be additional steps before Fewzion is operational. In such cases you will be notified in advance.
- Once the version is operational it’s up to you to run any further testing or integration you require. If your process requires us to redeploy the package to multiple targets (e.g: to your production servers, after testing/staging) this can be handled according to your Release Plan.
The specifics of your side of the process will be determined by assessment of your particular requirements and your level of/capacity for automation.
Please inform us of these details using the attached Release Plan form, or contact our support team.
We broadly categorise our communication channels so that the right people can respond in the fastest and most informative way.
Initial onboarding and requirements gathering will form the bulk of inbound administrative communication, however we expect to keep this channel active as your source of information and notice about delivery of our products and services.
|Inbound Examples||Outbound Examples|
|Some Fewzion policies etc found at||https://support.fewzion.com/hc/en-us/articles/203013979|
|Vannessa Wilson: 1300 FEWZION||Alex Retzlaff: email@example.com|
|Incident Reporting||Feature Requests|
|Suspected problems with Fewzion can be reported through the Fewzion Customer Portal which will be raised in our issue tracking systems. If we can validate the problem, we will immediately escalate it to our development team who will address it according to its priority.
For severe problems we will consider releasing a Patch version immediately instead of waiting for the next release cycle, provided your deployment plan allows for it.
|At all times throughout our development cycle we have clear and specific targets, both highly detailed short-term and less defined but still planned long term. Even so we are always welcoming of input from our end users.
Feature requests can be submitted at any time and we will assess them for inclusion based on their benefit and complexity. Typically we can not prioritise feature requests above bugs or inject them into a current development cycle.
|Support Hotline:||1300 FEWZION|
|Fewzion Client Support Plan found at||https://support.fewzion.com/hc/en-us/articles/203013979|