Serio Blog

Monday, 03 Jun 2019

This blog post is about timing considerations for the deployment of Changes into the IT infrastructure, specifically the batching together of Releases into a 'Release Window' (defined below) on the one hand, and the continuous deployment of Releases into the IT infrastructure on the other.

Deployment during a Release Window

A Release Window is an agreed time frame for deploying Releases into an IT environment (for example, each Thursday, or once every two weeks). Depending on the business demands of each company, Release Windows may be scheduled weekly, fortnightly, monthly, etc.

Typically, when Releases are scheduled, they are batched together and deployed simultaneously. This batching of Releases offers the opportunity to reduce downtime (for maintenance) to critical IT systems and is one of the principal benefits of this approach.

This comes at the expense of the time taken to deploy a particular Change, as you await the arrival of the next Release Window. Of course, Emergency Releases are not typically subject to a Release Window approach, but are instead deployed expediently.

Another advantage, it can be argued, is that it limits change into the IT infrastructure to specific times and therefore promotes stability.

Continuous Releases

In a Continuous Release environment each Release is deployed when it is ready to be deployed, and a suitable Release time/date is agreed.

Continuous Release allows for quicker deployment into the business environment since there is typically less wait time between a Release being ready for deployment and the actual deployment into the IT infrastructure. It could be argued it takes slightly less planning and management on the IT side.

However, there is potential for greater instability of the IT infrastructure, as well as more strain on gathering all resources necessary for each Release, due to more frequent deployment activities. Ultimately, Continuous Release may act as a trigger for greater unforeseen disruptions to the IT infrastructure and the business activities as a whole.

Thursday, 30 May 2019

Esta publicación está dirigida a las personas que trabajan con la Gestión de Cambios y/o están buscando introducir la Gestión de Registros de Versión.

En el despliegue de software y hardware, un Entorno de Producción se compone de la infraestructura de TI que admite las actividades cotidianas de la empresa.

Normalmente, se consideran 4 Entornos de TI al preparar una Solicitud de Despliegue:

  • Entorno de Desarrollo

Aquí es donde los desarrolladores coditan y ejecutan pruebas de funcionalidad inicial. Un ejemplo de un Entorno de Desarrollo es una plataforma IDE - Integrated Development Environment (Entorno de Desarrollo Integrado), que proporciona a los desarrolladores de software las herramientas necesarias al proceso de desarrollo

  • Entorno de Prueba

Este es el Entorno en el que se prueba el nuevo software y normalmente es una copia del Entorno de Producción

  • Entorno de UAT - User Acceptance Testing (Pruebas de Aceptación del Usuario)

El Entorno de Pruebas de Aceptación del Usuario es donde los usuarios reales del software lo prueban para evaluar si la funcionalidad del software cumple con los requisitos especificados

  • Entorno de Producción

Este es el Entorno en el que se despliega el software para uso de los usuarios finales.

Para cada uno de los 4 Entornos de TI mencionados arriba, tiene sentido crear un Registro de Versión específico, ya que cada Registro de Versión contiene instrucciones específicas para cada Entorno de TI.

Muchas empresas mantienen copias espejadas de su Entorno de Producción que permiten que los Cambios en su infraestructura se prueban completamente antes del despliegue en Producción.

Sin embargo, es importante tener en cuenta que cada empresa tiene sus propios procesos de Versión y, aunque he descrito 4 de los Entornos de TI más utilizados en Gestión de Versiones, no significa que se deban crear Registros de Versión para los 4 Entornos de TI cada vez que se planifica un Cambio de software.

El uso de diferentes Entornos de TI en el despliegue de software y hardware es sólo una norma de la industria puesta en práctica por grandes empresas, en su inmensa mayoría.

La decisión sobre cuales Entornos de TI son pertinentes con el fin de crear un Registro de Versión debe realizarse después de una cuidadosa consideración de la especificación y de la Evaluación del Impacto de cada Cambio.

Tuesday, 23 Apr 2019

This post is aimed at people who work with Change Management and/or are looking to introduce Release Record Management.

In software and hardware deployment a Production Environment is comprised of the IT infrastructure that supports the day to day activities of the business.

Typically, 4 IT Environments are considered when preparing a Request for Deployment:

  • Development Environment

This is where developers code and run initial functionality tests. An example of a Development Environment is an IDE (Integrated Development Environment) platform, which provides software developers with the tools necessary for the development process

  • Test Environment

This is the Environment in which the new software is tested and it’s typically a copy of the Live/Production Environment

  • UAT Environment

The User Acceptance Testing Environment is where the actual users of the software test to assess if the software functionality meets the specification requirements.

  • Live/Production Environment

This is the Environment where the software gets deployed to for the operation of the end users.

For all 4 IT Environments above, it makes sense to create a specific Release Record, as they carry instructions specific to each of them.

Many organisations maintain mirror copies of their Production (Live) Environment that allow Changes in their infrastructure to be fully tested before deployment into Production.

It is important to note however that each business has their own Release processes and although I have described 4 of the most commonly used IT Environments for Release Management, it does not mean that Release Records should be created for all 4 IT Environments everytime a software Change is planned.

The use of different IT environments in software and hardware deployment is only an industry norm put in practice by mainly large companies.

The decision about the relevant IT Environments for the purpose of creating a Release Record should be done after careful consideration of the Change specification and Impact Assessment.

Friday, 12 Apr 2019

This article is aimed at people who are engaged in Change Management but do not yet use Release Records.

Release Records (or Request For Deployment Records) are deliverables within the Change Management process and document:

  • the time window at which a Change is to be deployed into a particular IT environment,
  • who (typically the Teams) will deploy it,
  • the technical instructions on how to deploy
  • how to roll it back, if necessary.

By IT environment I simply mean the IT infrastructure into which the release is made - such as your Development Environment, Test or Production Environments (see our 'About IT environments' post for more information).

Each Release Record documents the progress of the Release through your different Environments and they are concerned with the technicalities of the actual deployment step, recording the exact date and time that this is planned to be made.

Here’s an example of the information held within the Release Records produced for a particular Change.

Change Ref No 829932 829932
Change description Patch SQL Server Management Studio Patch SQL Server Management Studio
Release environment Testing Production
Release Ref No 645 646
Teams involved Infrastructure, Networks Operations, Infrastructure, Networks
Release window / Start 13/04/2019 20:00 14/04/2019 20:00
Release window / End 14/04/2019 09:00 14/04/2019 21:00
Instructions [some technical instructions here] [some technical instructions here]
Rollback plan [some technical instructions to roll back, if nacessary, here] [some technical instructions to roll back, if nacessary, here]

Thinking about the Change as a whole, the Release Records associated with it are deliverables at each stage. Using Release Records to document a Change at each stage allows for businesses to refer to these records at later points in time and to improve the service continuously.

Tuesday, 09 Apr 2019

Our Development team has recently been focussing their attention in improving the use of Release Records within SerioPlus with the aims of allowing our customers quicker and more intuitive access to Release data.

Many improvements have been done in this front and are already available to use within SerioPlus:

  • Allowing multiple RFDs to be associated with a single Incident, Service Request, Problem or Change, making it easier to work with multiple RFDs for multiple environments 

  • Allowing RFDs to be associated with different types of Issue (Incidents, Service Requests, Problems, Changes) so that they can be used in situations where there is no Change Plan

  • The Release Record Listing report has also been improved and further to displaying key information about the RFD itself, it also associates each RFD to a particular Issue Reference within the system.

Friday, 27 Feb 2015

Serio Team is happy to announce the release of Serio 7 on March 15th, 2015!

Among many new features and improvements, Serio 7 introduces a fresh and renewed look throughout its applications.

Please see the Serio 7 Release page on our Serio website for a complete list of improvements and new features.

___________________

El equipo Serio se complace en anunciar el lanzamiento de Serio 7 el 15 de Marzo de 2015!

Entre muchas características nuevas y mejoras, Serio 7 introduce un aspecto fresco y renovado a través de sus aplicaciones.

Por favor, consulte la página de Lanzamiento Serio 7 en nuestro sitio web para obtener una lista completa de mejoras y nuevas características.

Wednesday, 11 Jun 2014

The team at Serio is happy to announce that a new release of SerioPlus is on the way.

The new release improves SerioPlus' overall functionality and gives Serio tools a fresh and renewed look, following the release of Serio's new website.

Serio Release 7

We've completely changed the colour schemes available, including new dark Android-style schemes, and changed the styles of the menus and buttons.

A completely redesigned Logging form

The new Logging form is designed to work with larger resolution screens, as well as the smaller screens we have always supported. In addition, it allows easier and faster capture of data and introduces new editable fields For example, it brings the Extended Data capture into the logging form, making it easier for Serio Agents to capture it and edit it right from the moment an Incident, Service Request, Problem or Change are logged.

Serio Relea\se 7 - logging form

Please stay alert for a full description of changes and improvements. We'll be posting further updates nearer the release date.

Tuesday, 17 Dec 2013

We're glad to announce that our Anti Spam Solution will be released on Saturday, 21st December 2013.

As described in the Anti Spam Update Details post, this system examines your Customer Database and checks the incoming email address against it, admitting only those emails whose sender is known to your Database.  This is done by checking both the customer's whole email address or the customer's domain, depending on your selected settings.

Please consider the following example.

l.thistle@teabythesea.com is a customer email address in your DB.

The following incoming email arrives at your Inbox: f.torrence@teabythesea.com and you have selected the 'Ensure that the Senders Domain Address Part is in the Serio Database' option.

Your Spam Filter checks this address against your customer DB  but cannot find that specific email address. However, the domain teabythesea.com is known to your Customer DB and therefore the email is admitted in your Inbox.

Should you have selected the 'Ensure that the Senders Whole Email Address is in the Serio Database' option instead, the email would be blocked and kept in your Spam Folder.

Furthermore, we've added the ability to Whitelist or Blacklist any domains and/or addresses you see fit.

All refused emails will sit on your Spam Folder and you'll be able to manually move any emails from that folder to your Inbox.

Please note that the only exception to our Anti Spam solution are emails containing reply references, such as the reference number affected to a logged Incident, Problem, Change or Service Request. In this case, the system receives the email and, should it contain a valid reference number, it will automatically be accepted in the Serio Inbox.

Again, this is an 'opt-in' system and those of you who haven't experienced Spam, can leave things as they are, should you choose to do so.

You'll be able to access the Anti Spam Filter from your SerioPlus Account Console (by clicking on the Serio logo from your SerioClient).

If you have any enquiries or suggestions about this, please get in touch through serio-support -at-serioplus -dot- com.

Monday, 04 Nov 2013

We've added an Extended Data Editor with new functionality within Actions and Change Plans.

  • Adding Extended Data to your Actions List

This will allow you to embed the capture of Extended Data into the Actions you take, and the workflow you use.

  • Viewing and adding Extended Data to Tasks in Change Plans

You can now capture and view Extended Data in a much simpler way. We've added the ability to create an Action that captures Extended Data, and then use that Extended Data in Tasks in your Change Plan.

For example, suppose one of your employees is leaving the company and you need to delete his email account. You will raise a Change, as usual, but you can now add an Action to capture the employee's username and department and then include this information directly in the text of future Tasks.

Suppose that you create an Extended Data definition called 'Deleted email account' (string type), and this is then set to joe.soap@mycompany.co.uk

You can include this in the Task

Account to Delete:  <</extended_start/>>Deleted Email Account<</extended_end/>>

So that when the Task is generated, the engineer sees

Account to Delete: joe.soap@mycompany.co.uk

We're expecting these changes to go live by the end of November.

Please let us know should you have any questions or want to make suggestions at serio-support-at-serioplus-dot-com.

Thursday, 31 Oct 2013

For those of you who've been experiencing some problems with Spam email in your Serio inboxes, we're letting you know that we're working on a solution for this.
Having resisted the urge to implement Bayesian spam filter system which would be detrimental to those who use their Inbox to receive a lot of machine-generated emails (such as monitoring alerts), we've decided to take a simpler and (what we believe is a) more effective approach, which keeps users in control..
We're working on an update that will allow you to filter incoming emails as follows:
1. Email arrives at your SerioPlus email address;
2. Serio looks for the email address of the sender and/or its domain email address and cross-matches it with the customer database we hold for you in SerioPlus;
3. If the address / domain is recognized, then Serio will let the email in you Serio inbox. If, on the other hand, Serio recognizes neither of them, then the email will be sent to a Spam List.
Another feature of this new update is that you will be able to move email from your Spam List to your inbox, should you decide so.
You will also be able to both whitelist or blacklist email addresses and/or domains of your choosing.
This change will be 'opt in', meaning that those of you who have not experienced spam can leave things as they are.
If you have any enquiries or suggestions about this, please get in touch through serio-support -at-serioplus -dot- com.
We expect this update to be ready by the end of November but we will let you know when this update goes live.

For those of you who've been experiencing some problems with Spam email in your Serio inboxes, we're letting you know that we're working on a solution for this.

Having resisted the urge to implement Bayesian spam filter system which would be detrimental to those who use their Inbox to receive a lot of machine-generated emails (such as monitoring alerts), we've decided to take a simpler and (what we believe is a) more effective approach, which keeps users in control.

We're working on an update that will allow you to filter incoming emails as follows:

  1. Email arrives at your SerioPlus email address;
  2. Serio looks for the email address of the sender and/or its domain email address and cross-matches it with the customer database we hold for you in SerioPlus;
  3. If the address / domain is recognized, then Serio will let the email in you Serio inbox. If, on the other hand, Serio recognizes neither of them, then the email will be sent to a Spam List.

Another feature of this new update is that you will be able to move email from your Spam List to your inbox, should you decide so.

You will also be able to both whitelist or blacklist email addresses and/or domains of your choosing.

This change will be 'opt in', meaning that those of you who have not experienced spam can leave things as they are.

If you have any enquiries or suggestions about this, please get in touch through serio-support -at-serioplus -dot- com.

We expect this update to be ready by the end of November but we will let you know when this update goes live.

Pages