Tuesday Notes – Releasing out of hours – 24/09/2019

Hey everyone,  

Here’s a few quick points on what I've been up to:

Podcast I'm listening to..

Jocko Podcast - Jocko Willink (American retired United States Navy SEAL) and Echo Charles discipline and leadership... extensively.


What I've read
 
 

Quote of the day

Don’t expect to be motivated every day to get out there and make things happen. You won’t be. Don’t count on motivation. Count on Discipline.


Releasing out of hours

We have just completed testing for a release that took 5 working days for 4 people (20 days of manual testing in total). A few issues here and there and we finished on time. This is a business critical release and the only time we could release is after working hours on a friday evening. We stayed up around 2 ½ hours late so it wasn’t that bad.

During the testing phase, there were 2 prevalent things to note:

  1. Regression tests die - As a team, we are given priorities based on the mission of the business and for this sprint, automation was not that.  A fair chunk of our automated tests were not updated so we had to them manually.
  2. Run smoke tests before testing and during testing phase- Many of the issues we found where found by our smoke tests. If we just continued testing without ensuring that the main functionality were working then we would’ve been less effective in testing.

Happy Testing!


 

2 Comments

  1. Releasing after close of business on a Friday sounds risky to me; unless you know that real-world users aren’t going to touch the app until Monday morning, you run the big risk of being woken at 2am on Saturday morning by a crisis.

    I know that there are situations when an out-of-hours release is the only option. I once tested a minor new feature which couldn’t even be tested until the end of business hours because there was NO TEST ENVIRONMENT. Just think about that for a moment. The client hadn’t put a test environment in place and so we were testing on the live environment after the day’s business transactions had all been processed. The only good thing was that I was paid by the hour on that gig, but the client insisted that I started work at 9am. So I was putting in big hours on that for comparatively little effort. The client had no joined-up thinking over managing their agency staff and ended up paying for it.

    Back to the question at hand. If releasing first thing on a Monday morning – a better time for a new release in terms of reacting to any glitches IRL – isn’t an option, then getting the team in on Sunday afternoon/ evening is probably preferable, even if it attracts premium payment rates. Attendees can be managed for numbers and times, the work will be concentrated down purely to what is necessary to roll the app out, and if users aren’t gong to be hitting the app until Monday morning, any issues will wait until then to be addressed. And no-one gets pulled out of bed at silly o’clock on a weekend, thus standing a better chance of thinking clearly about how to resolve issues.

    • One Man

      Hey Robert, what I didn’t mention in this post is that the team had to be confident of this release. We have a shared responsibility of the release and if one of us is uncomfortable with a release then we will not do it 🙂

      Testing in a live environment is not ideal at all. Was there no way for you to test in their local at the very least? I’ve heard from other teams that it also depends if the release is a minor or big change, I will definitely not be confident with testing something on the live environment when there are critical changes that might affect the system.

      You are right Robert, we’d want to minimise the chances of clients finding issues and also not risk our team getting burn out and not working in ideal hours. This is a very important point than you’ve touched upon as everyone has lives and we need to respect what they do out of working hours!

Leave a Reply

Your email address will not be published. Required fields are marked *