Difference between revisions of "Continuous Delivery"
Jump to navigation
Jump to search
| (19 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 10: | Line 16: | ||
* Hornbill is made up of a large number of independent micro-services. | * Hornbill is made up of a large number of independent micro-services. | ||
* Hornbill has 100% automated functional test coverage for functions used in production for all micro-services. | * Hornbill has 100% automated functional test coverage for functions used in production for all micro-services. | ||
| − | * Hornbill includes fast regression tests for elements (such as user experience) where it is not possible (or cost effective) to automate. | + | * Hornbill includes fast regression tests for elements (such as user experience) where it is not possible (or cost effective) to automate. |
| + | * Hornbill has a fully automated deployment pipeline, all packaging and deployment is done without human intervention. | ||
* Hornbill is organised into a small development teams who assume responsibility for feature and fix deployment. | * Hornbill is organised into a small development teams who assume responsibility for feature and fix deployment. | ||
| − | == Hornbill Update | + | == Hornbill Update Deployment Process == |
When we write code for a fix or a minor feature/enhancement we follow a strict methodology to facilitate both agility and continuous deployment. Each time we do a build, which are themselves fully automated, we have four stages of release before code makes it into production. These are known as '''test''', '''dev''', '''beta''' and '''live''' and every push of code has to transition through these four stages. Code can be blocked from progressing at any stage and for any reason. | When we write code for a fix or a minor feature/enhancement we follow a strict methodology to facilitate both agility and continuous deployment. Each time we do a build, which are themselves fully automated, we have four stages of release before code makes it into production. These are known as '''test''', '''dev''', '''beta''' and '''live''' and every push of code has to transition through these four stages. Code can be blocked from progressing at any stage and for any reason. | ||
| Line 20: | Line 27: | ||
* '''dev''' - all development instances used by Hornbill's development teams sit on this stream. Developers use many instances every day in the process of developing both our platform and our applications. Once a new build is available in '''dev''' all developer instances are automatically updated. This not only enables developers to validate recent code changes in a production environment but its our first line of defence to pick up anything unexpected. This is also where we run any manual regression testing that needs to be completed. The project build master will make a judgement about when a given build on '''dev''' is fit for promotion to the '''beta''' stream. A build will typically sit for 24 hours on '''dev''' before being pushed forwards. While on this stream we monitor performance, API and system logs to make sure there are no unexpected error conditions. If there are any problems then the build master for the project in question will reject the build which will prevent it moving forwards. | * '''dev''' - all development instances used by Hornbill's development teams sit on this stream. Developers use many instances every day in the process of developing both our platform and our applications. Once a new build is available in '''dev''' all developer instances are automatically updated. This not only enables developers to validate recent code changes in a production environment but its our first line of defence to pick up anything unexpected. This is also where we run any manual regression testing that needs to be completed. The project build master will make a judgement about when a given build on '''dev''' is fit for promotion to the '''beta''' stream. A build will typically sit for 24 hours on '''dev''' before being pushed forwards. While on this stream we monitor performance, API and system logs to make sure there are no unexpected error conditions. If there are any problems then the build master for the project in question will reject the build which will prevent it moving forwards. | ||
| − | * '''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, 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. 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]] | |
| − | == Hornbill Major "New" Feature | + | == Hornbill Major "New" Feature Update Process == |
| − | 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 | + | 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.
