Serio Blog

Wednesday, 26 Jun 2019

Esta publicación de blog trata sobre las consideraciones de tiempo para el despliegue de Cambios en la infraestructura de TI, específicamente el procesamiento por paquetes de versiones en una 'Ventana de Versión' (definida a continuación), por un lado, y el despliegue continuo de Versiones en la infraestructura de TI, por otro.

El despliegue durante una Ventana de  Versión

Una Ventana de Versión es un período de tiempo acordado para desplegar Versiones en un entorno de TI (por ejemplo, cada jueves o una vez cada dos semanas). Dependiendo de las demandas empresariales de cada empresa, las Ventanas de Versión pueden programarse semanalmente, quincenalmente, mensualmente, etc.

Normalmente, cuando se programan las Versiones, se agrupan por paquetes y se despliegan simultáneamente. Este procesamiento por paquetes de Versiones ofrece la oportunidad de reducir el tiempo medio de caída (para el mantenimiento) de los sistemas de TI críticos y es uno de los principales beneficios de este enfoque.

Esto se hace a expensas del tiempo necesario para desplegar un Cambio, mientras se espera la llegada de la siguiente Ventana de Versión. Por supuesto, las Versiones de Emergencia no suelen estar sujetas a una Ventana de Versión, sino que se despliegan de forma rápida.

Otra ventaja es que limita el cambio en la infraestructura de TI a tiempos específicos y, por lo tanto, promueve la estabilidad.

El Despliegue Continuo

En un entorno de Despliegue Continua de Versiones , cada Versión se despliega cuando está lista para desplegarse y se acuerda una hora/fecha adecuada para el despliegue de la Versión.

El Despliegue Continuo de Versiones permite un despliegue más rápido en el entorno empresarial, ya que normalmente hay menos tiempo de espera entre una Versión que está lista para el despliegue y el despliegue real en la infraestructura de TI. Se podría argumentar que se necesita un poco menos de planificación y gestión por el equipo de TI.

Sin embargo, existe la posibilidad de una mayor inestabilidad de la infraestructura de TI, así como una mayor presión en la recopilación de todos los recursos necesarios para cada Versión, debido a las actividades de despliegue más frecuentes. En última instancia, el Despliegue Continuo de Versiones puede actuar como un desencadenante de mayores interrupciones imprevistas en la infraestructura de TI y en las actividades empresariales en su conjunto.

Friday, 21 Jun 2019

Nuestro equipo de desarrollo ha estado recientemente trabajando en una interfaz entre SerioPlus y Twitter para permitir que los usuarios aprovechen la integración de las redes sociales en el sistema SerioPlus.

Esto permitirá a los usuarios de SerioPlus ofrecer servicios adicionales a sus clientes (por ejemplo, la administración del contenido en las redes sociales relacionado con el servicio que ofrecen a sus clientes).

El software se está extendiendo actualmente para que los usuarios de SerioPlus puedan manejar varias cuentas de Twitter desde su bandeja de entrada en SerioClient, brindando a sus clientes la posibilidad de interactuar directamente con su Mesa de Servicios, a través de Twitter.

Nuestro enfoque principal ha sido en los siguientes aspectos:

  • permitir que los usuarios de SerioPlus accedan a la timeline y las menciones de una cuenta de Twitter a través de la Bandeja de Entrada de Serio
  • permitir que los usuarios de SerioPlus respondan (o twitteen mensajes) a través de la Bandeja de Entrada de Serio.
  • permitir que los usuarios de SerioPlus registren Incidentes, Peticiones de Servicio o Cambios directamente desde un Tweet
  • permitir el manejo de varias cuentas de Twitter a través de la Bandeja de Entrada de Serio

Se puede esperar que esta nueva característica esté disponible en los próximos 3 meses.

Wednesday, 12 Jun 2019

Our development team has recently been working on an interface between SerioPlus and Twitter to allow users to take advantage of social media integration within SerioPlus Service Desk system.

 This will allow SerioPlus users to offer additional services to their customers (for example, the management of their service-related social media content).

The software is currently being extended so that SerioPlus users can handle multiple Twitter accounts from their SerioClient Inbox, providing their customers with the ability to interact directly with their Service Desk, via Twitter.

Our main focus has been on the following aspects:

  •  to allow SerioPlus users to access a particular Twitter account’s timeline and mentions through the Serio Inbox
  •  to allow SerioPlus users to reply to (or tweet messages) through the Serio Inbox.
  •  to allow SerioPlus users to log Incidents, Service Requests or Changes straight from an incoming Tweet
  •  to allow multiple Twitter accounts to be handled through the Serio Inbox.

You can expect this new feature to be available in the next 3 months.

Wednesday, 05 Jun 2019

Este artículo está dirigido a las personas que se dedican a la Gestión de Cambios, pero aún no utilizan los Registros de Versión.

Los Registros de Versión (o Registros de Solicitud de Despliegue) son entregables en el proceso de Gestión de Cambios y documentan:

  • el periodo de tiempo en el que se va a desplegar un Cambio en un determinado entorno de TI,
  • quién (normalmente los equipos) lo implementará,
  • las instrucciones técnicas sobre cómo desplegar
  • cómo retroceder, si necesario.

Por entorno de TI simplemente me refiero a la infraestructura de TI en la que se despliega la versión, como su Entorno de Desarrollo, Pruebas o Entornos de Producción (consulte nuestra publicación "Acerca de los Entornos de TI" para obtener más información).

Cada Registro de Versión documenta el progreso de la Versión a través de sus diferentes Entornos y se ocupa de los tecnicismos del despliegue, registrando la fecha y hora exactas que se planea realizar.

Este es un ejemplo de la información mantenida en los Registros de Versión creados para un Cambio determinado.

Número de Referencia del Cambio 829932 829932
Descripción del Cambio Actualización de SQL Server Management Studio Actualización de SQL Server Management Studio
Entorno de la Versión Prueba Producción
Número de Referencia de la Versión 645 646
Equipos involucrados Infraestructura, Redes Operaciones, Infraestructura, Redes
Ventana de Versión / Inicio 13/04/2019 20:00 14/04/2019 20:00
Ventana de Versión / Fin 14/04/2019 09:00 14/04/2019 21:00
Instrucciones [las instrucciones técnicas son introducidas aquí] [las instrucciones técnicas son introducidas aquí]
Plan de Reversión [las instrucciones técnicas para retroceder, si es necesario, son introducidas aquí] [las instrucciones técnicas para retroceder, si es necesario, son introducidas aquí]

Pensando en el Cambio en su conjunto, los Registros de Versión asociados a él son entregables en cada etapa. El uso de los Registros de Versión para documentar un Cambio en cada etapa permite a las empresas hacer referencia a estos registros en momentos posteriores y mejorar el servicio de forma continua.

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.

Pages