Para entrar rápidamente en producción con IBM® UrbanCode Release, lea los temas siguientes por orden.
Para planificar el release es necesario responder a algunas preguntas básicas acerca de su ámbito. ¿Es un release totalmente nuevo? ¿O utiliza un plan definido previamente? ¿Se trata de un release secundario, tal como un parche, que prácticamente no requiere ningún cambio en el release existente? Las respuestas a estas preguntas determinan su vía de acceso a producción y si puede volver a utilizar un release existente y, de ser así, hasta qué punto puede hacerlo.
Asegúrese de que las entradas para este tren del release proceden de una planificación sincronizada y abierta basada en equipo. El objetivo es definir un conjunto de componentes e interdependencias claramente articulado.
La vía de acceso a producción hace referencia a una serie de fases cuya culminación es la fase final, esto es, producción. En su definición más sencilla, una fase representa uno o varios entornos y los requisitos de calidad. Una fase puede tener también más elementos, por ejemplo, estados de calidad y puertas.
El progreso de las fases se define mediante un modelo de ciclo de vida. Cuando crea un release, se definen las fases disponibles para el mismo en el modelo de ciclo de vida seleccionado para el release. Si no es necesario definir una fase en un ciclo de vida, puede modificar el modelo o crear uno completamente nuevo. IBM UrbanCode Release proporciona un ciclo de vida predeterminado que puede modificar si lo prefiere.
La siguiente figura ilustra dos releases, Octubre y Noviembre, que utilizan el mismo modelo de ciclo de vida. Las fases definidas en el modelo se listan en la parte superior. Se asignan entornos a los releases y a cada fase se le asigna uno, como se muestra en la ilustración. Por ejemplo, el release Octubre, utiliza el entorno DEV-1 durante la fase DEV, mientras que el release Noviembre utiliza DEV-2 para dicha fase. En el modelo se definen las puertas entre las fases.
Se puede utilizar un ciclo de vida para cualquier número de releases. Si va variando los entornos y las aplicaciones (observe que la alineación de las aplicaciones es diferente entre los releases) puede diseñar releases para prácticamente cualquier eventualidad que surja en el mismo ciclo de vida. Si un ciclo de vida no resulta adecuado para un release concreto, por ejemplo, tiene demasiadas fases o no tiene las suficientes, puede crear un nuevo modelo de ciclo de vida en cualquier momento.
Puede utilizar IBM UrbanCode Release para trazar la ruta entre preproducción y producción y ejecutar con fiabilidad los releases en dicha ruta. El tren del release puede estar equipado con cualquier tipo de vehículo (procesos automatizados, manuales y ad hoc) y puede transportar cualquier tipo de carga. La planificación prevista para el tren del release dirige el proceso del release. Si utiliza IBM UrbanCode Release puede integrar y sincronizar la planificación basada en equipo para obtener un plan claro, abierto y transparente. Todas las partes interesadas conocen ahora los hitos y pueden estar seguras de que los releases avanzan según la planificación y llegan a su destino a tiempo.
En resumidas cuentas, la creación de un release significa utilizar la interfaz de usuario web para asignarle un nombre y seleccionar un ciclo de vida y el equipo. De forma más general, significa determinar si se trata de un release principal o secundario. Por regla general, un release secundario es aquel que puede utilizar entornos y aplicaciones existentes o un subconjunto de sus aplicaciones, y un release principal requiere nuevos entornos y aplicaciones.
Aunque las aplicaciones no son necesarias (puede crear un release que conste prácticamente de hitos y de tareas relacionadas con la infraestructura, por ejemplo), la mayor parte de los releases requieren el despliegue de aplicaciones. Las aplicaciones pueden proceder de la integración con herramientas externas, tales como IBM UrbanCode Deploy, o pueden haberse creado en IBM UrbanCode Release. Cada release tiene a su disposición todas las aplicaciones definidas en IBM UrbanCode Release. Puede asociar cualquier número de aplicaciones a un release.
Para obtener información acerca de cómo integrar IBM UrbanCode Release con herramientas externas, consulte Configuración de los proveedores de integración.
Las fases disponibles para un release se definen en el ciclo de vida que se ha seleccionado para el mismo. Puede resultar útil considerar un modelo de ciclo de vida como una plantilla que se utiliza para crear y dirigir releases. Un ciclo de vida define el progreso de las fases por las que pasa el software en su camino hacia producción, representada mediante una fase de producción, o hacia cualquier fase final similar designada. El ciclo de vida no especifica qué entornos concretos se utilizan para un release sino el patrón general. Por ejemplo, es posible que un ciclo de vida tenga las fases siguientes: Desarrollo, Control de calidad y Producción. Los releases basados en este ciclo de vida tienen las tres fases, aunque los entornos reales utilizados pueden variar de un release a otro. Un ciclo de vida también puede definir los pasos de calidad, denominados puertas, que deben realizarse correctamente para que el software pueda pasar a la fase siguiente.
Desarrolle estrategias adecuadas para cada fase. Las estrategias de producción de alto nivel pueden no ser adecuadas para los entornos de nivel inferior.
El primer paso para definir la vía de acceso a producción es determinar si se puede utilizar un modelo de ciclo de vida existente o si se requiere uno completamente nuevo. Por supuesto, si comienza totalmente de cero con IBM UrbanCode Release es necesario crear ciclos de vida que dupliquen sus procesos y entornos habituales. A medida que aumente su experiencia, desarrollará un grupo de ciclos de vida que podrá manejar prácticamente todos sus releases. Por lo tanto, las actividades necesarias para definir la vía de acceso a producción están determinadas, en gran parte, por la disponibilidad de ciclos de vida adecuados. Las siguientes tablas describen si está disponible o no un ciclo de vida reutilizable para una gran variedad de actividades.
Actividad | Descripción |
---|---|
1. Asignar un nombre a las fases del ciclo de vida. | Los entornos se correlacionan con las fases. |
2. Definir los estados. | Los estados son valores que define el usuario, por ejemplo, "Superado" o "Archivado". |
3. Añadir puertas. | Una puerta es un mecanismo que garantiza que no se pueden desplegar los elementos en una fase o entorno a menos que tengan un estado especificado por la puerta. Las puertas establecen un número mínimo de requisitos de entrada a una fase. |
Actividad | Descripción |
---|---|
1. Asignar entornos a fases. | Identificar los entornos que se utilizarán durante la fase de ciclo de vida. Un entorno de release es una construcción definida por el usuario que representa los destinos del despliegue. Un entorno de release agrega entornos de despliegue. |
2. Definir aprobaciones. | Una aprobación es un mecanismo que se utiliza para controlar entornos, independientemente de las consideraciones de calidad (estado). Se designan aprobadores por rol. Cualquier usuario con el rol especificado puede dar su aprobación. |
3. Seleccionar un plan de despliegue. | Un plan de despliegue define el nivel de organización y coordinación necesario para realizar correctamente el despliegue en una fase concreta. |
Las fechas de producción y preproducción conocidas se pueden registrar y distribuir planificando los despliegues en los entornos de release.
Las fechas se definen cuando se planifica un nuevo despliegue (
).Se crea un intervalo recurrente, o un despliegue recurrente, para aquellos despliegues que se repiten a intervalos pronosticables. Los intervalos recurrentes se pueden activar diariamente, semanalmente, por horas o mediante alguna expresión cron.
Los hitos son actividades, normalmente los elementos de la lista de comprobación del proceso, que se deben cumplir para que el release permanezca en su ruta. Un hito puede representar cualquier cosa que requiera seguimiento, por ejemplo una reunión inicial, una actualización del sistema operativo o actualizaciones de hardware y red. El seguimiento de los hitos se realiza por fecha y estado.
Los hitos se adjuntan al propio release y no a una fase o entorno concreto. Los hitos se crean en la página Release ( ).
Aunque puede resultar tentador concentrarse en las funciones identificadas durante la planificación, debe estar atento a los cambios potenciales que puedan cambiar el ámbito o afecten de algún modo a la planificación del tren del release.
Como puede haber adivinado, los equipos de release gestionan los releases. Un equipo consta de roles y de usuarios configurados en el sistema de seguridad de IBM UrbanCode Release. Un release debe tener configurado un rol. Los roles típicos son Administrador, Gestor del release y Usuario, y todos están disponibles de forma predeterminada. Los roles se pueden volver a utilizar.
Los roles se definen en la página Roles ( ).
Una aprobación es un mecanismo que se utiliza para controlar entornos, independientemente de las consideraciones de calidad (estado). Un release que requiere aprobación no podrá avanzar a una fase hasta que se le conceda la aprobación. Las aprobaciones se adjuntan a las fases. Se designan aprobadores por rol. Cualquier usuario con el rol especificado puede dar su aprobación.