Difference between revisions of "Continuous Delivery"
Jump to navigation
Jump to search
| (12 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | This document can now be found at its new location in the [https://docs.hornbill.com/hornbill-cloud/continuous-delivery Hornbill Document Library]. | ||
| + | |||
| + | [[file:hornbill-document-library.png|Hornbill Cloud|link=https://docs.hornbill.com/hornbill-cloud/continuous-delivery]] | ||
| + | |||
| + | <!-- | ||
| + | |||
Hornbill's platform and the applications that run on it are designed from the ground up to support [https://en.wikipedia.org/wiki/Continuous_delivery Continuous Delivery] for software releases. Our platform and applications are continuously and automatically updated to ensure that all of our customers always have the latest features and fixes, this is done completely automatically without any service down time and we guarantee that all customisations and integrations will continue to work. | Hornbill's platform and the applications that run on it are designed from the ground up to support [https://en.wikipedia.org/wiki/Continuous_delivery Continuous Delivery] for software releases. Our platform and applications are continuously and automatically updated to ensure that all of our customers always have the latest features and fixes, this is done completely automatically without any service down time and we guarantee that all customisations and integrations will continue to work. | ||
| Line 23: | Line 29: | ||
* '''beta''' - our beta steam is used by all pre-production instances. Hornbill's own production instances run on this stream, as do our beta test customers, some sandboxes, sales demo instances and partners instances. At this point we do not expect to see any issues but if anything does show up the build is blocked from progressing any further. While on this stream we monitor performance, API and system logs to make sure there are no unexpected error conditions. Once the build has been on '''beta''' for 48 hours without issue the build master for that project will promote the build to '''live'''. | * '''beta''' - our beta steam is used by all pre-production instances. Hornbill's own production instances run on this stream, as do our beta test customers, some sandboxes, sales demo instances and partners instances. At this point we do not expect to see any issues but if anything does show up the build is blocked from progressing any further. While on this stream we monitor performance, API and system logs to make sure there are no unexpected error conditions. Once the build has been on '''beta''' for 48 hours without issue the build master for that project will promote the build to '''live'''. | ||
| − | * '''live''' - our live stream is production. Once a build is pushed to live, all production instances will update themselves to that build. | + | * '''live''' - our live stream is production. Once a build is pushed to live, all production instances will update themselves to that build. Hornbill is an always upto date solution using continuous development and updates with 0 downtime occur throughout the day. However, for platform and applications that may require upto 2 minutes of downtime, occur at 0500 UTC for Platform and 0530 UTC for applications Mon-Fri. |
[[File:Cd_pipe.png|600px]] | [[File:Cd_pipe.png|600px]] | ||
| Line 30: | Line 36: | ||
If we add something major that is brand new, for example introduce a new application, a new report a new addtional view that did not previously exist then we simply follow the above '''Hornbill Update Process''' and leave the In-App training to guide our users to the new functionality. | If we add something major that is brand new, for example introduce a new application, a new report a new addtional view that did not previously exist then we simply follow the above '''Hornbill Update Process''' and leave the In-App training to guide our users to the new functionality. | ||
| − | == Hornbill Major "Change" | + | == Hornbill Major "Change" Update Process == |
| − | Our major change | + | Our major change update process is different to our continuous Update Process set out above. We are always conscious of our customers workflows and general usage expectations and do not just change the user experience or the way our system works. However, we do have to evolve and take our customers with us and we love adding great new features or sometimes significant step changes. In order to introduce such changes/features we provide Feature Option Switches that will allow users to switch between the new and existing behaviour/experience for a period of time known as the preview period, typically this is between 30 and 90 days depending on the feature and the feedback received during the feature preview. A typical workflow for this type of release would be as follows: - |
| − | * '''deploy''' - in oder to get the preview to our customers we follow the '''Hornbill Update | + | * '''deploy''' - in oder to get the preview to our customers we follow the '''Hornbill Update Process''' set out above. However, instead of enabling the feature we would typically provide an in-app notice indicating the presence of the new feature along with a feature switch right within the affected view(s) that are being changed. For example, at the time of writing this page we just introduced an all new Email interface which was substantially different (and improved) but as a result the user workflow was also substantially different. So we provided a "Try the new Xyz Feature" button which when pressed will switch the users session to use the new view, they would also have a button to switch back should they wish. Individual users can switch between the old and new way of working as they see fit. When the new feature is enabled, we will generally also provide a in-app link to documentation and/or a conversation to solicit feedback and allow users to ask us questions about the new feature. |
| − | * '''preview''' - we will leave the feature in preview for a period of time and react to any feedback by enhancing the new major feature using the '''Hornbill Update | + | * '''preview''' - we will leave the feature in preview for a period of time and react to any feedback by enhancing the new major feature using the '''Hornbill Update Process''' described above. |
* '''notice''' - once we are satisfied that the feature is fit for purpose and we have addressed any concerns from our user community we will issue notice to change, this is typically 30 days and will be shown in the application in the form of a countdown giving our users time to make the switch and adjust their workflow. | * '''notice''' - once we are satisfied that the feature is fit for purpose and we have addressed any concerns from our user community we will issue notice to change, this is typically 30 days and will be shown in the application in the form of a countdown giving our users time to make the switch and adjust their workflow. | ||
* '''finalise''' - on the planned date the option switch will be removed and all users will be switched over to the new feature. | * '''finalise''' - on the planned date the option switch will be removed and all users will be switched over to the new feature. | ||
* '''stand-off''' - we leave the now depreciated feature in the codebase for a stand-off period, typically 30 days and in an emergency Hornbill can revert to the old feature during this time. However, we would only do this in exceptional circumstances on a case by case basis and only to provide a short term work-around should a serious problem be found thats impacting a specific customer. | * '''stand-off''' - we leave the now depreciated feature in the codebase for a stand-off period, typically 30 days and in an emergency Hornbill can revert to the old feature during this time. However, we would only do this in exceptional circumstances on a case by case basis and only to provide a short term work-around should a serious problem be found thats impacting a specific customer. | ||
| + | |||
| + | == Patch Management == | ||
| + | Application Patches can be deployed seamlessly without need for end user involvement or downtime and will be applied when needed. | ||
| + | |||
| + | Platform Patches will either be Critical (Effect number of instances or security) or Emergency (Cannot wait until next scheduled release). Critical Patches will be applied when needed and may cause upto 1 minute of instance unavailability, Emergency Patches will be applied within the next update window (5AM UTC) | ||
| + | |||
| + | == Infrastructure Changes == | ||
| + | Hornbill is provisioned on fully redundant hardware and most changes can be made by our teams without any downtime. All infrastructure changes are conducted in the same cycle as software (Dev->Beta->Live) with the same time delays. Any Scheduled Maintenance that is expected to take longer than 2 minutes will be announced at least 7 days in advance (unless critical) via email to the nominated contacts. Scheduled maintenance of this type is usually performed before 0600 UTC Sat-Sun | ||
| + | |||
| + | --> | ||
| + | <!-- hornbill-cloud/continuous-delivery --> | ||
| + | [[Category:HDOC]] | ||
Latest revision as of 18:30, 11 April 2024
This document can now be found at its new location in the Hornbill Document Library.
