Difference between revisions of "Continuous Delivery"

From Hornbill
Jump to navigation Jump to search
 
(8 intermediate revisions by 2 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.  We have a instance-specific update windows that each customer can set, this means that updates only happen within the set window which is configured on an instance by instance basis but ensures that all live instances are updated within 24 hours of the build being pushed to live
+
* '''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 38: Line 44:
 
* '''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.

Hornbill Cloud