Envío y promoción del paquete
Cuando el paquete CCD esté listo, utilice la implementación de compilación automatizada para continuar. El proceso de implementación de compilación automatizada implica orquestar la promoción de la configuración y la personalización alineadas con los derechos y el panorama del entorno.
Se puede enviar una compilación cargando un paquete CCD y un fichero de manifiesto en las ubicaciones correspondientes de la cuenta de almacenamiento. Primero debe cargar el paquete CCD en /data/builds. A continuación, debe cargar el fichero de manifiesto en /data/builds/deploy.
Esta acción activa el proceso de trabajo de implementación de compilación automatizada. El proceso se rige mediante tareas de notificaciones recibidas por correo electrónico. La información del correo electrónico le guía por los distintos pasos. Los aprobadores de tareas se declaran en el fichero de manifiesto. Un ejemplo de un fichero de manifiesto está disponible en el tema Activar implementación automatizada.
 |
Considere los siguientes puntos como un requisito previo:
• Se debe definir una ubicación de Azure BLOB Storage. Los detalles de autorización se deben obtener de PTC Cloud.
◦ PTC le proporciona un URL de SAS para esta actividad.
◦ Debe enviar una solicitud con el portal de soporte de PTC para incluir su dirección IP en la lista de direcciones permitidas. En los detalles del caso, proporcione una dirección IP estable.
• Se debe enviar una solicitud para que el canal esté configurado para que coincida con el valor mencionado en el fichero de manifiesto. Algunos ejemplos son int1 o pipeline1. Para obtener más información sobre el atributo deploy_pipe, consulte la sección Creating Manifest File en el tema Activar implementación automatizada.
|
El primer paso del proceso de trabajo de implementación de compilación automatizada es la inspección del paquete CCD. El sistema inspecciona el paquete CCD para determinar si cumple las directrices de Windchill+. Después de la inspección, el sistema genera los informes y los pone a disposición en la cuenta de almacenamiento.
Los informes y registros se pueden encontrar en: /data/builds/logs/<RITM Number>/. La sintaxis de los informes y los ficheros de registro generados es la siguiente:
• Sintaxis de los informes: cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html. Aquí, <Control Label> puede ser IntakeProcessor, SpotBugs, Logs, etc.
• Sintaxis de los registros: ccd_<environment>_<Date-Time>_<ant target>_Logs.zip. Aquí, <ant target> puede ser deploy, load, etc. Para obtener más información, consulte Targets.
|
Nombre del informe
|
Verificaciones implementadas
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Verificaciones de Windchill+ (personalización permitida, desfasado, API no soportadas y seguridad de Windchill+)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
Verificación de código estático (prácticas recomendadas de Java)
|
Tenga en cuenta los siguientes puntos:
• Si el paquete CCD falla alguna de las verificaciones, se le envía una notificación y el proceso de envío se detiene.
• Si el paquete CCD cumple los requisitos, el proceso continúa y la compilación se promueve al destino definido en el fichero de manifiesto.
• Una vez que una implementación de compilación es correcta, tiene siete días para completar las pruebas.
|
|
Como cliente, usted es responsable del contenido del paquete CCD. Al enviar una compilación, usted certifica que el desarrollo se ha realizado respetando las directrices de seguridad de PTC. Para obtener información sobre las directrices de seguridad de PTC, consulte Security Customization Guidelines.
|
Barreras de seguridad de Windchill+ para la composición de un paquete de CCD
El paquete de CCD y su composición deben ajustarse a una estructura de directorios específica. Siga las barreras de seguridad indicadas para la estructura de directorios y el contenido de los ficheros de un paquete de CCD:
• El tamaño de un paquete de CCD no debe superar los 100 MB.
• El paquete de CCD puede contener las siguientes carpetas:
|
Carpeta
|
Descripción
|
|---|---|
|
Configurations
|
Ninguna o una carpeta Configurations
|
|
Generated
|
Ninguna o una carpeta Generated
|
|
customlib
|
Ninguna o una carpeta customlib
|
|
<custom module(s)>
|
Una o más carpetas de módulos personalizados
|
|
|
De las cuatro carpetas, al menos una debe estar presente en el paquete de CCD.
|
• El fichero descriptor.xml debe estar presente en todas las carpetas del módulo personalizado del paquete de CCD.
• La carpeta Generated puede estar vacía o puede contener una de las siguientes carpetas, o ambas:
◦ Carpeta db: la carpeta db puede estar vacía. De lo contrario, debe contener el fichero db/conf/SchemaConfig.xml.
◦ Carpeta BAC: solo se permite un fichero .zip BAC en la carpeta BAC. Las asignaciones de BAC se pueden proporcionar en el fichero Mapping.xsl que se encuentra en la carpeta BAC.
◦ customlib debe contener los ficheros jar de IP de socio, si los hay.
• Los valores de oferta permitidos son plusselect y meddev.
• Un paquete de CCD no debe contener ficheros bloqueados o inesperados, según las siguientes reglas:
◦ Lista de ficheros no permitidos en el paquete: .jar, .class, .exe, .ser, .sql, .ddl, .pks, .pkb, .ora, .jasper, .cs, .cpp, .so, .dll, .jnilib, .dylib, .h, .cgf, .out, .ldif, .sh,.pl, .groovy, .gwt.xml, .gwt.modules.xml
◦ Ficheros válidos dentro de la carpeta xconf: .xconf
◦ Ficheros válidos dentro de la carpeta conf: .xml, .ini
◦ Ficheros válidos dentro de la carpeta resources: .tpl, .bas, .ddx, .html, .yml, .xjb, .ftl, .xml, .dtd, .xsl, .properties, .txt, .ini, .json, .js
◦ Ficheros válidos dentro de la carpeta src: .java, .rbInfo
◦ Ficheros válidos dentro de la carpeta jsp: .jsp, .jspf
◦ Ficheros válidos dentro de la carpeta tags: .tag, .tagf
◦ Ficheros válidos dentro de la carpeta tlds: .tld
◦ Ficheros no permitidos dentro de la carpeta src_web: .java
◦ Ruta válida para la carpeta JasperReports: module/main/resources y module/main/src_web (no es válida en el nivel de configuración)
◦ Ficheros válidos en la carpeta JasperReports en la ruta de recursos: .jrxml, .jasperProperties y .properties
◦ Tipo de fichero válido en la carpeta JasperReports en la ruta src_web: .gif
◦ Ficheros válidos dentro de la carpeta customlib: .jar
◦ Las carpetas con el nombre apps no están permitidas dentro de las siguientes carpetas:
▪ configurations/resources
▪ main/resources
▪ main/src_web
Estas barreras de seguridad se comprueban cuando el paquete se envía para su implementación. Se notifica cualquier incumplimiento. En los registros de implementación se incluye un informe de resumen de RITM, por ejemplo, RITM0910921.txt. Este informe resume si el paquete cumple con las barreras de seguridad de Windchill+. A continuación se muestra un ejemplo de un informe de resumen de RITM:
Puede encontrar los registros detallados de RITM en un fichero zip de informe detallado que contiene estos detalles de verificación de barreras de seguridad. En este fichero zip se incluye un fichero de registro en el que se proporcionan los detalles de la verificación de barreras de seguridad.
Un ejemplo de un fichero zip es RITM0910921_Reports.zip.
Un ejemplo de un fichero de registro es preValidate_20240402-142645.log.
| | Aunque estas reglas no se apliquen, se deben tener en cuenta las desviaciones y corregirlas activamente. PTC aplicaría algunas de estas reglas en el futuro y cualquier incumplimiento invalidaría el paquete a partir de entonces. Para obtener más información sobre la personalización no permitida y los avisos, consulte Disallowed Customization. |
Antes de la puesta en marcha
Se puede utilizar Windchill+ sin el entorno de control de calidad. También puede utilizar la versión avanzada de Windchill+ con el entorno de control de calidad. En función del escenario, se pueden seguir los pasos mencionados en los siguientes enfoques:
Versión avanzada de Windchill+ con entorno de control de calidad
Realice los siguientes pasos al utilizar la versión avanzada de Windchill+ con el entorno de control de calidad:
1. Envíe el paquete al entorno de integración para el ciclo de pruebas de aceptación funcional e integración. Este ciclo de pruebas se puede activar con frecuencia. Por ejemplo, varias veces a la semana.
◦ Envíe un fichero de compilación y manifiesto con deploy_pipe : int.
Para obtener más información, consulte Implementación del paquete de código y configuración.
◦ Complete el ciclo de pruebas. Al final del ciclo de pruebas, la tarea se considera completada y el entorno vuelve a su estado anterior.
| | Si este paso no se completa en un plazo de siete días, el entorno vuelve automáticamente al estado anterior. |
2. Envíe el paquete al entorno de control de calidad para las UAT y luego promocione el paquete al entorno de producción. Se recomienda activar el ciclo de pruebas UAT una o dos veces al mes, ya que este proceso promueve la compilación al entorno de producción.
◦ Envíe un fichero de compilación y manifiesto con deploy_pipe : pipeline. Para obtener más información, consulte Implementación del paquete de código y configuración.
◦ Complete el ciclo de pruebas. Tenga en cuenta los siguientes puntos:
▪ Si el ciclo de pruebas se realiza correctamente, la tarea se aprueba y se promueve la compilación al entorno de producción.
▪ Si el ciclo de pruebas no se realiza correctamente, se rechaza la tarea y el entorno revierte al estado anterior.
▪ Si el ciclo de pruebas no se completa en un plazo de siete días, el entorno revierte a su estado anterior.
Versión básica de Windchill+ sin un entorno de control de calidad
Realice los siguientes pasos al utilizar una versión básica de Windchill+ Select sin un entorno de control de calidad:
1. Envíe un fichero de compilación y manifiesto con deploy_pipe : int. Para obtener más información, consulte Implementación del paquete de código y configuración.
2. Complete el ciclo de pruebas de aceptación funcional e integración. Al final del ciclo de pruebas, la tarea se ha completado y el entorno vuelve al estado anterior.
| | Si este paso no se completa en un plazo de siete días, el entorno vuelve a su estado anterior. |
3. Vuelva a enviar la misma compilación y un fichero de manifiesto actualizado con deploy_pipe : pipeline. Para obtener más información, consulte Implementación del paquete de código y configuración.
4. Complete el ciclo de pruebas de aceptación del usuario en el entorno de integración. Tenga en cuenta los siguientes puntos:
◦ Si el ciclo de pruebas se realiza correctamente: la tarea se aprueba y se promueve la compilación al entorno de producción.
◦ Si el ciclo de pruebas no se realiza correctamente: se rechaza la tarea y el entorno revierte al estado anterior.
◦ Si el ciclo de pruebas no se completa en un plazo de siete días, el entorno revierte automáticamente al estado anterior.
| | Todas las actividades de pruebas utilizan solo un entorno. El sistema solo puede realizar las actividades de pruebas de una en una. Si una compilación se envía utilizando deploy_pipe : int durante esta ventana, se rechaza automáticamente. |
Etapa de puesta en marcha
Una vez confirmada la etapa de puesta en marcha, es obligatorio realojar el entorno de producción en los entornos de control de calidad e integración.
Para esta actividad, se debe abrir una solicitud de servicio en el portal de soporte técnico de PTC. Para obtener más información, consulte Apertura de una solicitud de servicio.
Estado de ejecución
• Después de una puesta en marcha correcta, todos los entornos se realojan desde el entorno de producción. Por tanto, PTC recomienda encarecidamente propagar los cambios a los entornos de desarrollo. El enfoque recomendado es utilizar BAC y exportar un paquete BAC completo desde el entorno de integración. Para obtener más información, consulte Importing a BAC Package Using CCD Utility.
Tenga en cuenta los siguientes puntos:
◦ El modelo de datos es el mínimo que se debe exportar para volver a crear el sistema (administrador de tipos y atributos).
◦ Para los objetos no soportados por BAC, se puede exportar desde Integración desde la interfaz de usuario (cuando sea posible) o volver a crear el fichero de carga en el entorno de desarrollo.
• Después, el ciclo de envío es similar al que se menciona en la sección Antes de la puesta en marcha en el tema Envío y promoción del paquete.
• Después de la puesta en marcha principal, debe realojar el entorno de producción en los entornos de control de calidad e integración. Se debe abrir una solicitud de servicio para las actividades de realojamiento. Para obtener más información, consulte Apertura de una solicitud de servicio.
| | • Después de una puesta en marcha inicial correcta, todos los entornos (excepto el de desarrollo) se deben realojar desde producción. Este realojamiento no es automático y requiere una solicitud de servicio. • La puesta en marcha inicial hace referencia a la primera implementación de la aplicación en el entorno de producción. En este estadio, todos los entornos inferiores se sincronizan con la producción para garantizar la consistencia y la estabilidad en todo el panorama de implementación. • La puesta en marcha principal se refiere a cualquier versión posterior al entorno de producción después de la puesta en marcha inicial. Estas versiones suelen incluir nuevas funciones, mejoras o correcciones, y forman parte del ciclo de desarrollo y entrega en curso. |