Jump to content

Fully Automated Application Updates Are Coming!


Gerry

Recommended Posts

As I am sure you know, Hornbill platform updates are fully automatic and happen without any human intervention, ensuring you are always on the latest software versions, this is part of our continuous delivery development process and strategy and we have been doing this since 2015 when we introduced the Hornbill platform.   However, I am also sure you that you know, while the platform is kept up to date, applications are not, its left up to you as an administrator to do the update by simply pressing the "Update" button in the Hornbill app store. 

One of most requested platform changes we have had at every Hornbill INSIGHTS meeting is for us to extend the automated updates to applications that are installed on your instance, so I am delighted to be able to tell you that we have now reached the point where we are able to do this and will be turning this on over the next 2-3 weeks.  The main sticking point for us this end was building out, and ensuring we had robust automated testing for each application, which we are now satisfied we have achieved. 

Once we switch over, application updates will be automatically applied to your instance within the maintenance window you have set. You will also receive email notifications advising you of updates to applications when they happen just like you do for platform updates (assuming you have that configured). 

You will see that the "Update" button will still be present in the Admin tool when there are new updates, so if there is a need to update in an emergency, for example, if we pushed an urgent hot-fix that you need to apply, you could do that immediately without having to wait for the maintenance window. However, when updates are made available, they will be applied automatically at the first opportunity within the maintenance window configured for your instance. 

This was a much requested change that I know a lot of you have been asking for, expect to see this change in the next 2-3 weeks. 

Thanks
Gerry

  • Like 5
Link to comment
Share on other sites

@Gerry

As a software company who also provides hosted solutions we appreciate the importance of keeping versions up to date and trying to minimise versions across an estate; However there are occasions where we have change freezes on critical system which includes Service Manager where we do not apply application updates. A recent example would be during our out of hours elections support for the recent general election. Therefore will there be the option to disable automatic application updates for a period of time?

Also from a change control point of view, if there are applied on the first opportunity after release, there may not be time for system administrator to review the impact from the release notes and inform the users of any changes and impact. For example the recent UI changes to the timeline.

As been raised previously , the current maintenance window is only set-able within a 24 period. As we are operating 24/7 on the system we would prefer to be able to set the maintenance window to a specific day(s) so to minimise the impact on the operation.

I agree automatic update of applications is a good and welcome addition, but I think there does need to be some improvement in the maintenance scheduling window capability, the ability to have a standard minimum delay/timeout before a new version is applied (i.e. to allow the system admin to review the release notes) and support for change freeze.

Cheers

Martyn

Link to comment
Share on other sites

Hi Gerry

Will there be a published schedule of when these updates would take place at all? Would it be a set date each week / month or would these updates potentially be implemented any day? The reason I ask is for any updates I have implemented to date, these are discussed and agreed at our weekly CAB meetings.

If there is an option for us to specify a date for these updates to allow us to be able to present the changes to our CAB? I note you do mention these updates will be implemented within a specified window set by ourselves?

Many thanks

  • Like 1
Link to comment
Share on other sites

@Adrian Simpkins

@Martyn Houghton

Hi Guys, thanks for the questions, let me try to answer them as there are a few points I should probably cover. 

With regards to having a capability of adding some control over the "days of the week", with our current development methodology this is not practical. For the platform, we have adopted a "Continuous Delivery" approach from day one. This means, all customers are always on exactly the same version of the software at all times. Now it is critical (because our development processes make this assumption) that updates are applied incrementally and sequentially. For example, suppose build 10 is out in "live", then we push build 11 to live, we know that within 24 hours all "live" instances will be on build 11,  and sometimes we have to gate the next build because there are incremental dependancies, in other words, we cannot push build 12 until we know that build 11 is already on the tarket PODs. If we had a situation where a customer could effectively gate the update by say limiting the update to only Sundays, then just one customer doing that would mean we would now be unable to push build 12 until the next Sunday maintenance window.  For this reason, it is simply not possible to provide a means by which you can control the update schedule by days. 

It is really important to highlight something else.  When we first built the Hornbill platform, every instance had its own set of physical processes and run entirely in isolation of every other instance.  Over time thought, more and more of that architecture has become multi-tenanted, and while we are not there today, we are moving towards a full micro-services architecture and when we get to that point, processes and systems are shared by multiple customers, and this means that over time, even the maintenanceWindow setting will become obsolete, and will be replaced by the fact that there will be zero service disruption during updates, as many elements of the platform already work like this. 

In terms of the published updates schedule, not really.  On the platform we generally push twice weekly, being Tuesdays and Thursdays, but this is not rigid, we can actually push updates at any time, sometimes we can push every day, it depends on what we need to do. Our release streams contain fixes, changes and new capabilities, and we do our best not to gate anything. Of course, along with this, we also ensure that we do not break any compatibility along the way, so platform updates should be largely invisible to our customers.  We have used the same mechanism for automated application updates, and part of this is adopting the same CD development methodology and practices we are already well versed in with the platform.  Our overall goal is to ensure our customers have an evergreen and always up to date service, removing the overhead entirely that is normally associated with updates, CAB and change control normally associated with enterprise software. 

Now before anyone panics, I wanted to ask a question to give this some perspective. Do you use Office 365 in your organisation?  If the answer to that is yes (which it is for most everyone now days)

- Do you have any option to gate or regulate updates to the O365 service to specific times or days?
- Do you get advanced notice and/or release notes of updates that are applied to O365?
- Do you take changes to the O365 service into your CAB meetings?
- Do you have any idea what version of O365 your organisation is using?

What we are aiming for with the Hornbill service is the same thing.

Hopefully, while not the answers you are possibly looking for, I hope the explanation makes some sense.  Happy to discuss further. 

Gerry

Link to comment
Share on other sites

@Martyn Houghton

"Also from a change control point of view, if there are applied on the first opportunity after release, there may not be time for system administrator to review the impact from the release notes and inform the users of any changes and impact. For example the recent UI changes to the timeline."

Yes I understand, but what we try our best to do, is to only ever make changes that are incremental, we try to bring our users through the journey with us.  We will never change anything so drastically that your users could get confused or lost, we do make subtle changes all the time, this is how we keep things fresh and always modern and up to date.  In the case where we make changes that are impactful from a working practice point of view, say we completely redesign the UI, then we provide an option to "switch on the feature" and try it for a while, giving people the opportunity to get comfortable with large changes. 

If we do make changes that cause issues then we really need to know about them so we can understand what we got wrong, you mentioned "recent UI changes to the timeline", can you provide me some specifics here? as I really need to feed that back to the team(s) that need to know. 

Basically, we should not be making any changes that cause disruption to your day to day use, we would like to think that as a service provider we largely remove the need for a system administrator to have to review impact of changes altogether, just in the same way as Microsoft has done with 0365 and many other cloud based services do. 

Gerry

 

Link to comment
Share on other sites

@Gerry

The example of I was referencing was the Activity Stream rewrite introduced in Collaboration Build 1120 which caused introduced a brand new timeline view and problems such as PM00158398 in relation to re-instating the option to open emails using the right click -> open in a new tab. As this was a Collaboration Build this was applied as per the proposed process for applications on the next maintenance windows which would have been within 24 hours of the release/announcement being made.

My main point is visibility, in the example above I do not believe there was any pre-announcement about the intended change, where as in the past we have had the option to turn elements on to evaluate and feedback on. This approach compliments you own testing process and helps to improve the product for all of our benefit.

Perhaps a compromise, is  if the announcement is made on the forum, a few workings days ahead of the release being pushed to live, so any questions or concerns can be raised ahead of time. Along with the use where appropriate of the method of providing a preview setting ahead for a short period of time before it is applied by default.

Will this also mean that application updates will be more frequent and smaller, as the perception is that they have become less frequent and larger?

On a side note, with Office 365 tenants you do have the option to control your update frequency to manage risk  and undertake targeted deployments. I am not suggesting you apply a 'Semi-Annual' process ;)

https://docs.microsoft.com/en-us/deployoffice/change-management-for-office-365-clients#Options

I am not suggesting you apply a 'Semi-Annual' process ;) and agree automated updates are a good thing, but as above a bit more visibility at least.

Cheers

Martyn

 

Link to comment
Share on other sites

@Martyn Houghton

Thanks for the clarification, I have had a quick look.  With regards to PM00158398 I can only apologise for this, it was simply an oversight on our part. The function this relates to is what we internally call a "plug-in". The Timeline component is developed as part of the collaboration core, and in order to allow applications to extend the core capability, application teams are provided a facility to "plug-in" to the timeline to add application-specific functionality.  It would appear from the internal descriptions of the solution, we failed to fully recognise the purpose of the plug-in function, that was simply our error, I do not want to dismiss it because we should not make mistakes like that but it does happen from time-to-time, I will make sure I feed this back to the team(s). 

I cannot hand on hand say that we will never make a mistake, we will from time to time, we are in the software business and thats the nature of the beast.  However, one of the great benefits of automated software updates is, if we do cause a problem, we are empowered to fix and deeply really quickly, which overall should be a far greater benefit to our customers I would hope. 


With regards to more frequent updates - one of the positive side-effects of automated updates is we can do more frequent updates, little and often is always good in software development, less likely to create significant problems along the way.  Now thats not to say that we will be pushing loads of updates, but 2 a week would be typical I would expect.  It is also worth noting that sometimes we have what might look like update breaks where you see nothing for a couple of weeks, this is typically aligned to things like security fixes, technical debt or major change where we switch into project-like mode for a short period, each app team is autonomous so it will be different on an app-by-app and platform basis. 

On your point about O365 clients, yes you are right, for the on-prem deployed clients, they follow a different path. I was referring to 0365 in the cloud/browser, there is no such controls for that :)

 

Gerry





 

Link to comment
Share on other sites

Hi Gerry

Thanks for the above explanation on the approach to updates. Personally, I like the idea of taking the task of updates away from myself :) However, other interested parties within my organisation are nervous around changes outside of our control, I will just have to sell this approach to them, and will use O365 as a good example

Some kind of heads up on the Forum would more than suffice - I will let you know of any feedback when I check this with the CAB team.

Many thanks !

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

@Adrian Simpkins

To be honest you have been getting automated platform updates from day one, it is really just an extension of that. As true cloud application is a "service", and it really should not need the consumer of the service to do anything other than use the service.   Most modern cloud services are like this, and I think the enterprise is slowly getting more comfortable with the approach, as you say 0365 is a perfect example of that. 

We provide the service to you, that means we have the headaches of updates, change management and so on, leaving you free to just consume the service. We do everything we can to ensure our customers have no disruptions to their daily routines, and when something bad does go wrong, grab yourself a coffee and relax, and we do all the running around and sweating to get it all sorted out. 

If O365 went down, although we could, I very much doubt we would contact Microsoft, because we know its likely to be back within a few minutes. I think more and more we are getting used to cloud services like this. 
 

Gerry

  • Like 1
Link to comment
Share on other sites

Hi Gerry

Thank you for the comments, totally understand the approach, and the fact more and more software is handled via the cloud without the need for manual updates by the Customers. I am sure this will be ok with the CAB forum members as they should all be familiar with this approach for other cloud based products.

Many thanks as always !

Link to comment
Share on other sites

@Adrian Simpkins

Thanks for your response and for being on the journey with us, Hornbill is an amazing company mostly because it has amazing customers doing amazing things.  Everything we do is about trying to make life at work just that little bit better and I hope this is one less mundane job for you guys to have to worry about or take care of. 

Gerry

Link to comment
Share on other sites

  • 4 weeks later...

@Jeremy

This will be turned on for all instances, our aim is to align fully with the way the platform updates work so they just happen automatically.   There are two main drivers for this... the majority of customers are asking for this, but secondly, our continuous delivery & fail forward development approach really requires it.  What we have found is some customers simply do not press the update button at all, and some times we need them to in order to deliver the new stuff that customers are asking for, this means we end up forever chasing customers to go and press the update button on their app(s), so this enables us to unify our update planning and be a little more agile when it comes to the application roadmaps

Gerry

Link to comment
Share on other sites

  • 2 weeks later...

Hi Paul,

I'm one of the people who had questions about how this would work outside CAB control previously.

I expect that you'll be removing the facility to manual take updates from Home => Applications: will there be a revised summary dashboard detailing release content along with a schedule of when you intend to apply updates to the various modules, so that even though they'll be delivered automatically, we'll be able to both advise our service desk and be ready to review/check functionality in areas where fixes/changes have been applied?

Will you be providing a similar dashboard to provide details of updates to on-premises utility programs such as the LDAP import and asset import?

Thanks.

Trevor. 

Link to comment
Share on other sites

  • 1 month later...
Guest Paul Davis

Hi @Trevor Tinsley

Sorry, I missed your question until it was just now pointed out to me. The delivered changes for Hornbill Platform and Application builds will continue to be communicated via the Announcements section in the Customer Forums and also can be found under the Latest Changes tile from Home>System. There is not advance notice, which I think you were asking about, and no formalised release schedule, as in keeping with the continuous delivery approach. That said, a 90-day view of Development work is though provided for the Service Manager application on the Success Portal for customers subscribing to the Premier Success Plan. The delivery mechanism for open source integration tools made available on Github will continue unchanged.

As per my update in another post a short while back, this change has been pushed back due to the current situation with COVID19. 

Regards,

Paul 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...