Integración continua - Guía rápida

La integración continua se introdujo por primera vez en el año 2000 con el software conocido como Cruise Control. A lo largo de los años, la integración continua se ha convertido en una práctica clave en cualquier organización de software. Esta es una práctica de desarrollo que requiere que los equipos de desarrollo se aseguren de que se lleve a cabo una compilación y pruebas posteriores para cada cambio de código realizado en un programa de software. Este concepto estaba destinado a eliminar el problema de encontrar incidencias tardías de problemas en el ciclo de vida de la compilación. En lugar de que los desarrolladores trabajaran de forma aislada y no se integraran lo suficiente, se introdujo la integración continua para garantizar que los cambios de código y las compilaciones nunca se hicieran de forma aislada.

¿Por qué la integración continua?

La integración continua se ha convertido en una parte muy integral de cualquier proceso de desarrollo de software. El proceso de Integración continua ayuda a responder las siguientes preguntas para el equipo de desarrollo de software.

  • ¿Todos los componentes del software funcionan juntos como deberían? - A veces, los sistemas pueden volverse tan complejos que existen múltiples interfaces para cada componente. En tales casos, siempre es fundamental asegurarse de que todos los componentes del software funcionen a la perfección entre sí.

  • ¿Es el código demasiado complejo para fines de integración? - Si el proceso de integración continua sigue fallando, podría existir la posibilidad de que el código sea demasiado complejo. Y esto podría ser una señal para aplicar patrones de diseño adecuados para hacer que el código sea menos complejo y más fácil de mantener.

  • ¿El código se adhiere a los estándares de codificación establecidos? - La mayoría de los casos de prueba siempre comprobarán que el código se adhiere a los estándares de codificación adecuados. Al hacer una prueba automatizada después de la compilación automatizada, este es un buen punto para verificar si el código cumple con todos los estándares de codificación deseados.

  • ¿Cuánto código cubren las pruebas automatizadas? - No tiene sentido probar el código si los casos de prueba no cubren la funcionalidad requerida del código. Por lo tanto, siempre es una buena práctica asegurarse de que los casos de prueba escritos cubran todos los escenarios clave de la aplicación.

  • ¿Fueron satisfactorias todas las pruebas después del último cambio? - Si una prueba falla, entonces no tiene sentido continuar con la implementación del código, por lo que este es un buen punto para verificar si el código está listo para pasar a la etapa de implementación o no.

Flujo de trabajo

La siguiente imagen muestra un flujo de trabajo rápido de cómo funciona todo el flujo de trabajo de integración continua en cualquier proyecto de desarrollo de software. Veremos esto en detalle en los capítulos siguientes.

Entonces, según el flujo de trabajo anterior, generalmente así es como funciona el proceso de integración continua.

  • Primero, un desarrollador confirma el código en el repositorio de control de versiones. Mientras tanto, el servidor de Integración Continua en la máquina de construcción de integración sondea el repositorio de código fuente en busca de cambios (por ejemplo, cada pocos minutos).

  • Poco después de que se produzca una confirmación, el servidor de integración continua detecta que se han producido cambios en el repositorio de control de versiones, por lo que el servidor de integración continua recupera la última copia del código del repositorio y luego ejecuta un script de compilación, que integra el software.

  • El servidor de integración continua genera comentarios enviando por correo electrónico los resultados de la construcción a los miembros del proyecto especificados.

  • Luego, se realizan pruebas unitarias si se aprueba la construcción de ese proyecto. Si las pruebas tienen éxito, el código está listo para implementarse en el servidor de ensayo o de producción.

  • El servidor de Integración continua continúa sondeando los cambios en el repositorio de control de versiones y todo el proceso se repite.

La parte del software es el aspecto más importante de cualquier proceso de Integración Continua. Este capítulo se centra en el software que será necesario para todo el proceso de Integración Continua.

Repositorio de código fuente

El repositorio de código fuente se utiliza para mantener todo el código fuente y todos los cambios realizados en él. Los dos más populares para la gestión de repositorios de código fuente son la subversión y Git, siendo Git el sistema popular más reciente. Ahora veremos cómo instalar Git en el sistema.

Requisitos del sistema

Memoria 2 GB de RAM (recomendado)
Espacio del disco Disco duro de 200 MB para la instalación. Se requiere almacenamiento adicional para almacenar el código fuente del proyecto y esto depende del código fuente que se agregue.
Versión del sistema operativo Se puede instalar en Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Instalación de Git

Step 1 - El sitio web oficial de Git es https://git-scm.com/. Si hace clic en el enlace, accederá a la página de inicio del sitio web oficial de Git como se muestra en la siguiente captura de pantalla.

Step 2 - Para descargar Git, simplemente desplácese hacia abajo en la pantalla y vaya a la sección Descargas y haga clic en Descargas.

Step 3 - Haga clic en el enlace de Windows y la descarga de Git comenzará automáticamente.

Step 4- Haga clic en el archivo .exe descargado para Git. En nuestro caso, estamos usando el archivo Git-2.6.1-64-bit.exe. Haga clic en Ejecutar que aparece en la siguiente pantalla.

Step 5 - Haga clic en el botón Siguiente que aparece en la siguiente pantalla.

Step 6 - Haga clic en Siguiente en la siguiente pantalla para aceptar el acuerdo de licencia general.

Step 7 - Elija la ubicación para su instalación de Git.

Step 8 - Haga clic en Siguiente para aceptar los componentes predeterminados que deben instalarse.

Step 9 - Elija la opción de 'Usar Git desde el símbolo del sistema de Windows' ya que vamos a usar Git desde Windows.

Step 10 - En la siguiente pantalla, acepte la configuración predeterminada de 'Realizar la compra al estilo de Windows, confirmar los finales de línea al estilo Unix' y haga clic en Siguiente.

Step 11 - En la siguiente pantalla, elija la opción de 'Usar ventana de consola predeterminada de Windows', ya que estamos usando Windows como sistema para la instalación de Git.

La instalación comenzará ahora y se pueden seguir los pasos posteriores para configurar Git, una vez que se complete la instalación.

Configurando Git

Una vez que se ha instalado Git, los pasos de configuración deben llevarse a cabo para la configuración inicial de Git.

Lo primero que debe hacerse es configurar la identidad en Git y luego configurar un nombre de usuario y correo electrónico. Esto es importante porque cadaGit commitusa esta información, y se integra de manera inmutable en las confirmaciones que comienzas a crear. Uno puede hacer esto abriendo el símbolo del sistema y luego ingresando los siguientes comandos:

git config –global user.name “Username”
git config –global user.email “emailid”

La siguiente captura de pantalla es un ejemplo para una mejor comprensión.

Estos comandos realmente cambiarán el archivo de configuración de Git en consecuencia. Para asegurarse de que su configuración haya surtido efecto, puede enumerar la configuración del archivo de configuración de Git mediante la emisión del siguiente comando.

git config --list

En la siguiente captura de pantalla se muestra un ejemplo de la salida.

Servidor de integración continua

El siguiente software crucial requerido para toda la tubería de integración continua es el propio software de Integración Continua. A continuación, se muestran los softwares de integración continua más utilizados en la industria:

  • Jenkins- Este es un software de integración continua de código abierto que es utilizado por muchas comunidades de desarrollo.

  • Jet Brains TeamCity - Este es uno de los software de integración continua comercial más populares disponibles y la mayoría de las empresas lo utilizan para sus necesidades de integración continua.

  • Atlassian Bamboo- Este es otro software de integración continua popular proporcionado por una empresa llamada Atlassian Pvt. Limitado.

Todos los softwares mencionados anteriormente funcionan en el mismo modelo de Integración Continua. Para el propósito de este tutorial, veremosJetbrains TeamCity para el servidor de integración continua.

Instalación de TeamCity

Los siguientes son los pasos y los requisitos del sistema para instalar Jet Brains TeamCity en su computadora.

Requisitos del sistema

Memoria 4 GB de RAM (recomendado)
Espacio del disco Disco duro de 1 GB para la instalación. Se requiere almacenamiento adicional para almacenar el espacio de trabajo de construcción para cada proyecto.
Versión del sistema operativo Se puede instalar en Windows, Linux, Mac OS X.

Instalación

Step 1 - El sitio web oficial de TeamCity eshttps://www.jetbrains.com/teamcity/. Si hace clic en el enlace dado, irá a la página de inicio del sitio web oficial de TeamCity como se muestra en la siguiente captura de pantalla. Puede navegar por la página para descargar el software necesario para TeamCity.

Step 2 - El .exe descargado se utiliza con el fin de ejecutar TeamCity-9.1.6.exe. Haga doble clic en el ejecutable y luego haga clic en Ejecutar en la siguiente pantalla que aparece.

Step 3 - Haga clic en Siguiente para iniciar la configuración.

Step 4 - Haga clic en el botón 'Acepto' para aceptar el acuerdo de licencia y continuar con la instalación.

Step 5 - Elija la ubicación para la instalación y haga clic en Siguiente.

Step 6 - Elija los componentes predeterminados para la instalación y haga clic en Siguiente

Esto iniciará el proceso de instalación. Una vez completado, seguirá el proceso de configuración.

Step 7- Elija un número de puerto para que se ejecute el servidor. Lo mejor es utilizar un puerto diferente como8080.

Step 8- A continuación, preguntará con qué cuenta debe ejecutarse TeamCity. Elija la cuenta del SISTEMA y haga clic en Siguiente.

Step 9- A continuación, preguntará por los servicios que deben iniciarse. Acepte los predeterminados y luego haga clic en Siguiente.

Configuración de TeamCity

Una vez que se completa la instalación, el siguiente paso es la configuración de TeamCity. Este software se puede abrir navegando en la siguiente URL en el navegador:

http://locahost:8080

Step 1- El primer paso es proporcionar la ubicación de las construcciones, que serán realizadas por TeamCity. Elija la ubicación deseada y haga clic en el botón Continuar.

Step 2- El siguiente paso es especificar la base de datos para almacenar todos los artefactos de TeamCity. A los efectos del tutorial, se puede elegir elInternal (HSQLDB), que es una base de datos interna que es más adecuada cuando se utilizan productos con fines de prueba.

TeamCity luego procesará todos los pasos necesarios para ponerlo en funcionamiento.

Step 3- A continuación, se le pedirá que acepte el acuerdo de licencia. Acepte lo mismo y haga clic en Continuar.

Step 4- Debe crear una cuenta de administrador que se utilizará para iniciar sesión en el software TeamCity. Ingrese los detalles requeridos y haga clic en el botón 'Crear cuenta'.

Ahora iniciará sesión en TeamCity.

La herramienta de construcción

La herramienta Construir es una herramienta que asegura que el programa se construya de una manera particular. La herramienta normalmente llevará a cabo una lista de tareas, que son necesarias para que el programa se construya de manera adecuada. Dado que en nuestro ejemplo, vamos a ver un.Net program , estaremos mirando MSBuildcomo herramienta de construcción. La herramienta MSBuild examina un archivo de compilación que contiene una lista de tareas que se utilizan para compilar el proyecto. Veamos un archivo de compilación típico para un proyecto de configuración web.

A continuación se muestran las secciones clave del archivo de compilación, que deben tenerse en cuenta.

Configuración de IIS

Las siguientes configuraciones se utilizan para determinar cuál es el número de puerto, cuál es la ruta en el servidor web y qué tipo de autenticación se requiere cuando se ejecuta la aplicación. Estas son configuraciones importantes, que se cambiarán a través del comando MSBuild cuando sepamos cómo se llevará a cabo la implementación más adelante en el tutorial.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Esto se usa para decirle al servidor de compilación cuáles son todos los binarios dependientes que se requieren para ejecutar este proyecto.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

Versión de .Net Framework

los TargetFrameworkVersionindica cuál es la versión de .Net que debe estar presente para que el proyecto funcione. Esto es absolutamente necesario porque si el servidor de compilación no lo tiene, la compilación fallará.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Entorno de implementación: Amazon

Para el propósito de este tutorial, nos aseguraremos de que nuestro servidor de Integración Continua tenga la capacidad de implementar nuestra aplicación en Amazon. Para ello, debemos asegurarnos de que los siguientes artefactos estén en su lugar.

Servidor de base de datos

Realice los siguientes pasos para asegurarse de que el servidor de base de datos esté instalado en Amazon para la implementación.

Step 1 - Vaya a la consola de Amazon - https://aws.amazon.com/console/.

Inicie sesión con sus credenciales. Tenga en cuenta que puede solicitar una identificación gratuita en el sitio de Amazon, lo que le permitirá tener un nivel gratuito que le permitirá utilizar algunos de los recursos de Amazon de forma gratuita.

Step 2 - Vaya a la Sección RDS para crear su base de datos.

Step 3 - Haga clic en Instancias en la siguiente pantalla que aparece.

Step 4 - Haga clic en el Launch DB opción en la siguiente pantalla que aparece.

Step 5 - Elija la pestaña SQL Server y luego elija la opción Seleccionar para SQL Server Express.

Step 6 - Asegúrese de ingresar los siguientes detalles para confirmar que está utilizando el nivel gratuito de bases de datos disponibles en Amazon.

Step 7 - Haga clic en el botón Paso siguiente una vez que se hayan completado todos los campos.

Step 8 - En la siguiente pantalla que aparece, acepte todas las configuraciones predeterminadas y haga clic en Launch DB Instance.

Step 9- A continuación, se le presentará una pantalla que dice que la base de datos se está iniciando correctamente. En la misma página, habrá un botón para ver la instancia de base de datos. Haga clic en el enlace para ver suDB Instance siendo configurado.

Después de un tiempo, el estado de la pantalla anterior cambiará para notificar que la instancia de base de datos se ha creado correctamente.

Servidor web

El siguiente paso es crear su servidor web en Amazon, que albergará la aplicación web. Esto se puede hacer siguiendo los pasos siguientes para tenerlo en su lugar.

Step 1 - Ir a la consola de Amazon - https://aws.amazon.com/console/.

Inicie sesión con sus credenciales. Tenga en cuenta que puede solicitar unfree id on the Amazon site, lo que le permitirá tener un nivel gratuito que le permitirá utilizar algunos de los recursos en Amazon de forma gratuita.

Step 2 - Ir al EC2 section para crear su servidor web.

Step 3 - En la siguiente pantalla, haga clic en Iniciar instancia.

Step 4 - Haga clic en Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Elija el t2.microopción, que forma parte del nivel gratuito. Hacer clicNext: Configure Instance Details.

Step 6 - Acepte la configuración predeterminada en la siguiente pantalla que aparece y luego elija la opción Next: Add Storage.

Step 7 - Acepte la configuración predeterminada en la siguiente pantalla y elija la opción Next: Tag Instance.

Step 8 - Acepte la configuración predeterminada en la siguiente pantalla y elija la opción de Next: Configure Security Group.

Step 9 - Acepte la configuración predeterminada en la siguiente pantalla y elija la opción de Review and Launch.

Step 10 - Haga clic en Iniciar en la siguiente pantalla que aparece.

Step 11- En la siguiente pantalla que aparece, se le pedirá que cree un par de claves. Esto se utilizará para iniciar sesión en el servidor en un momento posterior. Simplemente cree el par de claves y haga clic enLaunch Instance.

La instancia ahora se configurará en Amazon.

Hay posibilidades de que las cosas salgan mal en un proyecto. Al practicar la IC de manera efectiva, descubre lo que sucede en cada paso del camino, en lugar de más tarde, cuando el proyecto está en el ciclo de desarrollo. CI lo ayuda a identificar y mitigar los riesgos cuando ocurren, lo que facilita la evaluación y el informe sobre el estado del proyecto en función de evidencia concreta.

Esta sección se concentrará en los riesgos que se pueden evitar mediante la integración continua.

En cualquier proyecto, existen muchos riesgos que deben gestionarse. Al eliminar los riesgos en una etapa temprana del ciclo de vida del desarrollo, hay menos posibilidades de que estos riesgos se conviertan en problemas más adelante, cuando el sistema se active.

Riesgo 1: falta de software implementable

“It works on my machine but does not work on another”- Esta es probablemente una de las frases más comunes que se encuentran en cualquier organización de software. Debido a la cantidad de cambios que se realizan a diario en las compilaciones de software, a veces hay poca confianza en si la compilación del software realmente funciona o no. Esta preocupación tiene los siguientes tres efectos secundarios.

  • Poca o ninguna confianza en si podríamos construir el software.

  • Fases de integración prolongadas antes de entregar el software internamente (es decir, el equipo de prueba) o externamente (es decir, el cliente), durante las cuales no se hace nada más.

  • Incapacidad para producir y reproducir construcciones comprobables.

Solución

Eliminando el acoplamiento estrecho entre el IDE y los procesos de construcción. Utilice una máquina separada únicamente para integrar el software. Asegúrese de que todo lo que necesita para construir el software esté contenido en el repositorio de control de versiones. Finalmente, cree un sistema de Integración Continua.

El servidor de integración continua puede observar los cambios en el repositorio de control de versiones y ejecutar el script de creación del proyecto cuando detecta un cambio en el repositorio. La capacidad del sistema de Integración Continua se puede aumentar para incluir que la compilación se ejecute a través de pruebas, realice inspecciones e implemente el software en los entornos de desarrollo y prueba; de esta manera siempre tendrá un software en funcionamiento.

“Inability to synchronize with the database”- A veces, los desarrolladores no pueden volver a crear la base de datos rápidamente durante el desarrollo y, por lo tanto, les resulta difícil realizar cambios. A menudo, esto se debe a una separación entre el equipo de base de datos y el equipo de desarrollo. Cada equipo se centrará en sus propias responsabilidades y tendrá poca colaboración entre ellos. Esta preocupación tiene los siguientes tres efectos secundarios:

  • Miedo a hacer cambios o refactorizar la base de datos o el código fuente.

  • Dificultad para llenar la base de datos con diferentes conjuntos de datos de prueba.

  • Dificultad para mantener los entornos de desarrollo y prueba (por ejemplo, desarrollo, integración, control de calidad y prueba).

Solución

La solución al problema anterior es asegurarse de que se lleve a cabo la ubicación de todos los artefactos de la base de datos en el repositorio de control de versiones. Esto significa todo lo que se requiere para recrear el esquema y los datos de la base de datos: se necesitan secuencias de comandos de creación de bases de datos, secuencias de comandos de manipulación de datos, procedimientos almacenados, activadores y cualquier otro activo de la base de datos.

Reconstruya la base de datos y los datos de su secuencia de comandos de compilación, soltando y recreando su base de datos y tablas. A continuación, aplique los procedimientos almacenados y los desencadenadores y, finalmente, inserte los datos de prueba.

Pruebe (e inspeccione) su base de datos. Normalmente, utilizará las pruebas de componentes para probar la base de datos y los datos. En algunos casos, deberá escribir pruebas específicas de la base de datos.

Riesgo 2: descubrir defectos al final del ciclo de vida

Dado que hay tantos cambios que ocurren con frecuencia por parte de varios desarrolladores en el código fuente, siempre hay posibilidades de que se pueda introducir un defecto en el código que solo podría detectarse en una etapa posterior. En tales casos, esto puede causar un gran impacto porque cuanto más tarde se detecta el defecto en el software, más caro resulta eliminar el defecto.

Solución

Regression Testing- Este es el aspecto más importante de cualquier ciclo de desarrollo de software, prueba y prueba nuevamente. Si hay algún cambio importante en el código del software, es absolutamente obligatorio asegurarse de que se ejecuten todas las pruebas. Y esto se puede automatizar con la ayuda del servidor de Integración Continua.

Test Coverage- No tiene sentido realizar pruebas si los casos de prueba no cubren toda la funcionalidad del código. Es importante asegurarse de que los casos de prueba creados para probar la aplicación estén completos y de que se prueben todas las rutas de código.

Por ejemplo, si tiene una pantalla de inicio de sesión que debe probarse, simplemente no puede tener un caso de prueba que tenga el escenario de un inicio de sesión exitoso. Debe tener un caso de prueba negativo en el que un usuario ingrese una combinación diferente de nombres de usuario y contraseñas y luego se requiere ver qué sucede en tales escenarios.

Riesgo 3: falta de visibilidad del proyecto

Los mecanismos de comunicación manual requieren mucha coordinación para garantizar la difusión de la información del proyecto a las personas adecuadas de manera oportuna. Inclinarse hacia el desarrollador que está a su lado y hacerle saber que la última versión está en la unidad compartida es bastante efectivo, pero no se escala muy bien.

¿Qué pasa si hay otros desarrolladores que necesitan esta información y se encuentran en un descanso o no están disponibles? Si un servidor falla, ¿cómo se le notifica? Algunos creen que pueden mitigar este riesgo enviando manualmente un correo electrónico. Sin embargo, esto no puede garantizar que la información se comunique a las personas adecuadas en el momento adecuado, ya que puede omitir accidentalmente a las partes interesadas y es posible que algunas no tengan acceso a su correo electrónico en ese momento.

Solución

La solución a este problema es nuevamente el servidor de integración continua. Todos los servidores de CI tienen la posibilidad de tener correos electrónicos automatizados que se activan cada vez que fallan las compilaciones. Mediante esta notificación automática a todas las partes interesadas clave, también se garantiza que todos estén a bordo sobre cuál es el estado actual del software.

Riesgo 4: software de baja calidad

Hay defectos y luego hay defectos potenciales. Puede tener defectos potenciales cuando su software no está bien diseñado o si no sigue los estándares del proyecto o es complejo de mantener. A veces, la gente se refiere a esto como olores de código o de diseño: "un síntoma de que algo puede estar mal".

Algunos creen que el software de menor calidad es únicamente un costo del proyecto diferido (después de la entrega). Puede ser un costo de proyecto diferido, pero también genera muchos otros problemas antes de entregar el software a los usuarios. El código demasiado complejo, el código que no sigue la arquitectura y el código duplicado, todos suelen provocar defectos en el software. Encontrar estos olores de código y diseño antes de que se manifiesten en defectos puede ahorrar tiempo y dinero, y puede conducir a un software de mayor calidad.

Solución

Hay componentes de software para realizar un control de calidad del código que se pueden integrar con el software CI. Esto se puede ejecutar después de que se haya creado el código para garantizar que el código realmente se ajuste a las pautas de codificación adecuadas.

Los sistemas de control de versiones, también conocidos como control de fuente, sistemas de administración de código fuente o sistemas de control de revisión, son un mecanismo para mantener múltiples versiones de sus archivos, de modo que cuando modifique un archivo aún pueda acceder a las revisiones anteriores.

El primer sistema de control de versiones popular fue una herramienta patentada de UNIX llamada SCCS(Sistema de control de código fuente) que se remonta a la década de 1970. Esto fue reemplazado porRCS, el sistema de control de revisiones y posteriores CVS, Sistema de Versiones Simultáneas.

Ahora, el sistema de control de versiones más utilizado es Subversion y Git. Primero veamos por qué necesitamos usar un sistema de control de versiones y luego veamos cómo poner nuestro código fuente enGit source code repository system.

Propósito del sistema de control de versiones

Una razón por la que usamos el término control de versiones en lugar de control de fuentes es que el control de versiones no es solo para el código fuente. Cada artefacto relacionado con la creación de su software debe estar bajo control de versiones.

    Developers should use it for source code - De forma predeterminada, todo el código fuente debe almacenarse en el sistema de control de versiones

    Related artefacts- Cada sistema tendría artefactos relacionados con el código fuente, como scripts de base de datos, scripts de construcción e implementación, documentación, bibliotecas y archivos de configuración para su aplicación, su compilador y colección de herramientas, etc. Todos estos complementan todo el proceso de desarrollo e implementación y también deben almacenarse en el sistema de control de versiones.

Al almacenar toda la información de la aplicación en el control de código fuente, es más fácil volver a crear los entornos de prueba y producción en los que se ejecuta la aplicación. Esto debe incluir información de configuración para la pila de software de su aplicación y los sistemas operativos que componen el entorno, archivos de zona DNS, configuración de firewall, etc.

Como mínimo, necesita todo lo necesario para volver a crear los archivos binarios de su aplicación y los entornos en los que se ejecutan. El objetivo es tener almacenado de forma controlada todo lo que pueda cambiar en cualquier momento de la vida del proyecto. Esto le permite recuperar una instantánea exacta del estado de todo el sistema, desde el entorno de desarrollo al entorno de producción, en cualquier momento del historial del proyecto.

Incluso es útil mantener los archivos de configuración para los entornos de desarrollo del equipo de desarrollo en el control de versiones, ya que facilita que todos los miembros del equipo utilicen la misma configuración. Los analistas deben almacenar los documentos de requisitos. Los evaluadores deben mantener sus scripts y procedimientos de prueba en control de versiones. Los gerentes de proyecto deben guardar sus planes de lanzamiento, gráficos de progreso y registros de riesgos aquí.

En resumen, cada miembro del equipo debe almacenar cualquier documento o archivo relacionado con el proyecto en control de versiones.

Trabajar con Git para el sistema de control de versiones de código fuente

Esta sección ahora se centrará en cómo se puede utilizar Git como sistema de control de versiones. Se centrará en cómo puede cargar su código en el sistema de control de versiones y administrar los cambios en él.

Nuestra aplicación de demostración

Para el propósito de todo este tutorial, veremos un simple Web ASP.Netaplicación que se utilizará para todo el Proceso de Integración Continua. No necesitamos centrarnos en todos los detalles del código para este ejercicio, solo tener una descripción general de lo que hace el proyecto es suficiente para comprender todo el proceso de integración continua. Esta aplicación .Net fue construida usando elVisual Studio Integrated Development Environment.

La siguiente captura de pantalla es la estructura de la solución en el entorno de Visual Studio. Es una aplicación web muy simple que tiene el código principal en elDemo.aspx archivo.

El código en el archivo Demo.aspx se muestra en el siguiente programa:

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

El código es muy simple y solo envía la cadena "Integración continua" al navegador.

Cuando ejecuta el proyecto en Google Chrome, el resultado será como se muestra en la siguiente captura de pantalla.

Mover el código fuente a Git

Vamos a mostrar cómo mover el código fuente a Git desde la interfaz de línea de comandos, para que el conocimiento de cómo se puede usar Git sea más claro para el usuario final.

Step 1 - Inicializar el Git Repository. Vaya al símbolo del sistema, vaya a la carpeta de su proyecto y emita el comandogit init. Este comando agregará los archivos de Git necesarios a la carpeta del proyecto, de modo que Git pueda reconocerlo cuando sea necesario cargarlo en el repositorio.

Step 2- Agregar sus archivos que deben agregarse al repositorio de Git. Esto se puede hacer emitiendo elgit add command. La opción de punto le dice a Git que todos los archivos en la carpeta del proyecto deben agregarse al repositorio de Git.

Step 3- El paso final es enviar los archivos del proyecto al repositorio de Git. Este paso es necesario para garantizar que todos los archivos ahora formen parte de Git. El comando a emitir se da en la siguiente captura de pantalla. los–m option es proporcionar un comentario sobre la carga de archivos.

Su solución ahora está disponible en Git.

A continuación se presentan algunas de las principales características o prácticas de la integración continua.

  • Maintain a single source repository- Todo el código fuente se mantiene en un único repositorio. Esto evita que el código fuente se encuentre disperso en varias ubicaciones. Herramientas comoSubversion and Git son las herramientas más populares para mantener el código fuente.

  • Automate the build- La construcción del software debe realizarse de manera que pueda automatizarse. Si hay varios pasos que deben llevarse a cabo, entonces la herramienta de compilación debe ser capaz de hacerlo. Para .Net, MSBuild es la herramienta de compilación predeterminada y para las aplicaciones basadas en Java tiene herramientas comoMaven and Grunt.

  • Make your build self-testing- La construcción debe ser comprobable. Inmediatamente después de que se produzca la compilación, se deben ejecutar casos de prueba para garantizar que se puedan realizar las pruebas para las diversas funciones del software.

  • Every commit should build on an integration machine- La máquina de integración es el servidor de compilación y debe asegurarse de que la compilación se ejecute en esta máquina. Esto significa que todos los componentes dependientes deben existir en el servidor de integración continua.

  • Keep the build fast- La construcción debería ocurrir en minutos. La compilación no debería tardar horas en realizarse, porque esto significaría que los pasos de compilación no están configurados correctamente.

  • Test in a clone of the production environment- El entorno de construcción debe ser de naturaleza cercana al entorno de producción. Si existen grandes diferencias entre estos entornos, puede darse el caso de que la compilación falle en producción aunque pase al servidor de compilación.

  • Everyone can see what is happening - Todo el proceso de construcción, prueba e implementación debe ser visible para todos.

  • Automate deployment- La integración continua conduce a la implementación continua. Es absolutamente necesario asegurarse de que la compilación sea fácil de implementar en un entorno de ensayo o de producción.

A continuación se muestra la lista de los requisitos más importantes para la integración continua.

  • Check-In Regularly- La práctica más importante para que la integración continua funcione correctamente son los controles frecuentes en el tronco o en la línea principal del repositorio de código fuente. El registro del código debe realizarse al menos un par de veces al día. Registrarse regularmente trae muchos otros beneficios. Hace que los cambios sean más pequeños y, por lo tanto, es menos probable que se rompa la construcción. Significa que se conoce la versión más reciente del software a la que se puede volver cuando se comete un error en cualquier compilación posterior.

    También ayuda ser más disciplinado sobre la refactorización del código y ceñirse a pequeños cambios que preservan el comportamiento. Ayuda a garantizar que los cambios que alteran una gran cantidad de archivos tengan menos probabilidades de entrar en conflicto con el trabajo de otras personas. Permite a los desarrolladores ser más exploradores, probar ideas y descartarlas volviendo a la última versión comprometida.

  • Create a Comprehensive Automated Test Suite- Si no tiene un conjunto completo de pruebas automatizadas, una compilación aprobada solo significa que la aplicación se puede compilar y ensamblar. Si bien para algunos equipos este es un gran paso, es esencial tener algún nivel de pruebas automatizadas para brindar confianza de que su aplicación realmente está funcionando.

    Normalmente, hay 3 tipos de pruebas realizadas en Integración Continua a saber unit tests, component testsy acceptance tests.

    Las pruebas unitarias están escritas para probar el comportamiento de pequeñas partes de su aplicación de forma aislada. Por lo general, se pueden ejecutar sin iniciar toda la aplicación. No llegan a la base de datos (si su aplicación tiene una), al sistema de archivos ni a la red. No requieren que su aplicación se ejecute en un entorno de producción. Las pruebas unitarias deben ejecutarse muy rápido: todo su conjunto, incluso para una aplicación grande, debe poder ejecutarse en menos de diez minutos.

    Las pruebas de componentes prueban el comportamiento de varios componentes de su aplicación. Al igual que las pruebas unitarias, no siempre requieren iniciar toda la aplicación. Sin embargo, pueden afectar la base de datos, el sistema de archivos u otros sistemas (que pueden estar bloqueados). Las pruebas de componentes suelen tardar más en ejecutarse.

  • Keep the Build and Test Process Short - Si se tarda demasiado en compilar el código y ejecutar las pruebas unitarias, se encontrará con los siguientes problemas.

    • La gente dejará de hacer una compilación completa y ejecutará las pruebas antes de registrarse. Comenzará a tener más compilaciones fallidas.

    • El proceso de integración continua tomará tanto tiempo que se habrán realizado varias confirmaciones para cuando pueda ejecutar la compilación nuevamente, por lo que no sabrá qué registro rompió la compilación.

    • Las personas se registrarán con menos frecuencia porque tienen que sentarse durante años esperando que se compile el software y se ejecuten las pruebas.

  • Don’t Check-In on a Broken Build- El mayor error de la integración continua es verificar una compilación defectuosa. Si la compilación se rompe, los desarrolladores responsables están esperando para solucionarlo. Identifican la causa de la rotura lo antes posible y la arreglan. Si adoptamos esta estrategia, siempre estaremos en la mejor posición para averiguar qué causó la rotura y solucionarlo de inmediato.

    Si uno de nuestros colegas ha realizado un registro y, como resultado, ha roto la compilación, entonces, para tener la mejor oportunidad de solucionarlo, necesitará una prueba clara del problema. Cuando se rompe esta regla, inevitablemente se tarda mucho más en arreglar la construcción. La gente se acostumbra a ver que la construcción está rota, y muy rápidamente te encuentras en una situación en la que la construcción permanece rota todo el tiempo.

  • Always Run All Commit Tests Locally Before Committing- Asegúrese siempre de que las pruebas diseñadas para la aplicación se ejecuten primero en una máquina local antes de ejecutarlas en el servidor CI. Esto es para garantizar que se escriban los casos de prueba correctos y si hay alguna falla en el proceso de CI, es debido a los resultados de la prueba fallidos.

  • Take Responsibility for All Breakages that Result from Your Changes- Si realiza un cambio y todas las pruebas que escribió pasan, pero otras se rompen, la compilación aún no funciona. Por lo general, esto significa que ha introducido un error de regresión en la aplicación. Es su responsabilidad, debido a que realizó el cambio, corregir todas las pruebas que no se aprueben como resultado de sus cambios. En el contexto de la IC, esto parece obvio, pero en realidad no es una práctica común en muchos proyectos.

Hay una variedad de herramientas de construcción disponibles para una variedad de lenguajes de programación. Algunas de las herramientas de construcción más populares incluyenAnt for Java y MSBuild for .NET. El uso de una herramienta de secuencias de comandos diseñada específicamente para la creación de software, en lugar de un conjunto personalizado de secuencias de comandos de shell o por lotes, es la forma más eficaz de desarrollar una solución de creación coherente y repetible.

Entonces, ¿por qué necesitamos un proceso de construcción para empezar? Bueno, para empezar, para un servidor de integración continua, el proceso de compilación debe ser fácil de trabajar y debe ser transparente de implementar.

Tomemos un ejemplo simple de cómo puede verse un archivo de compilación para .Net:

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Los siguientes aspectos deben tenerse en cuenta sobre el código anterior:

  • Un objetivo se especifica con el nombre de la compilación. En donde, un objetivo es una colección de pasos lógicos que deben realizarse en un proceso de construcción. Puede tener varios objetivos y tener dependencias entre los objetivos.

  • En nuestro objetivo, mantenemos un mensaje de opción que se mostrará cuando comience el proceso de construcción.

  • los MSBuild task se utiliza para especificar qué proyecto .Net debe construirse.

El ejemplo anterior es un caso de un archivo de construcción muy simple. En la integración continua, se garantiza que este archivo se mantenga actualizado para garantizar que todo el proceso de compilación sea fluido.

Construyendo una solución en .Net

La herramienta de compilación predeterminada para .Net es MSBuild y se incluye con el marco .Net. Dependiendo del marco de su sistema, tendrá disponible la versión de MSbuild correspondiente. Por ejemplo, si tiene .Net framework instalado en la ubicación predeterminada, encontrará elMSBuild.exe archivo en la siguiente ubicación -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Veamos cómo podemos construir nuestro proyecto de muestra. Supongamos que nuestro proyecto de muestra se encuentra en una carpeta llamadaC:\Demo\Simple.

Para usar MSBuild para construir la solución anterior, necesitamos abrir el símbolo del sistema y usar la opción MSBuild como se muestra en el siguiente programa.

msbuild C:\Demo\Simple\Simple.csproj

En el ejemplo anterior, csprojes el archivo de proyecto que es específico de .Net. El archivo csproj contiene toda la información relevante para garantizar que la información requerida esté presente para que el software se compile correctamente. A continuación se muestra la captura de pantalla de la salida del comando MSBuild.

No necesita preocuparse por las advertencias de salida siempre que la compilación se haya realizado correctamente y no haya errores.

Ahora veamos ciertos aspectos del archivo MSBuild para ver qué significan. Es importante conocer estos aspectos a partir de un ciclo de integración continuo.

Los scripts de compilación se utilizan para compilar la solución, que será parte de todo el ciclo de integración continuo. Veamos el script de compilación general que se crea como parte de Visual Studio en.Netpara nuestra solución de muestra. El script de compilación es bastante grande, incluso para una solución simple, por lo que repasaremos las partes más importantes. De forma predeterminada, el script de compilación se almacenará en un archivo con el mismo nombre que la solución principal en Visual Studio. Entonces, en nuestro caso, si abre el archivoSimple.csproj, verá todas las configuraciones que se utilizarán para construir la solución.

  • Dependencia de la versión de MSBuild utilizada: la siguiente configuración usará los archivos de MSBuild instalados en el servidor de CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />
  • ¿Qué archivos se necesitan para construir la solución correctamente? ItemGroupLa etiqueta contendrá todos los archivos .Net necesarios para que el proyecto se compile correctamente. Estos archivos deberán residir en el servidor de compilación en consecuencia.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>
  • ¿Cuáles son las configuraciones del servidor web que se utilizarán? Cuando visitemos nuestro tema de Implementación continua, verá cómo se usará MSBuild para anular estas configuraciones e implementarlas en nuestro servidor de elección.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

El siguiente paso importante es asegurarse de que la solución se base en el servidor de compilación. La primera parte es un paso manual, porque antes de utilizar la herramienta de integración continua, primero debemos asegurarnos de que la compilación se ejecute en el servidor de compilación de la misma manera que se hizo en la máquina cliente. Para hacer esto, debemos implementar los siguientes pasos:

Step 1- Copie todo el archivo de la solución al servidor. Creamos un servidor de instancias de Amazon que se usaría como nuestro servidor de compilación. Entonces, haga una copia manual en el servidor de todo.Net solución en el servidor.

Step 2- Asegúrese de que el marco esté presente en el servidor. Si ha compilado su aplicación en .Net framework 4.0 en su máquina cliente, debe asegurarse de que esté instalada también en la máquina servidor. Así que ve a la ubicaciónC:\Windows\Microsoft.NET\Framework en su servidor y asegúrese de que esté presente el marco deseado.

Step 3 - Ahora ejecutemos MSBuild en el servidor y veamos qué sucede.

Bien, parece que hemos encontrado un error. Hay una lección importante en la integración continua y es que debe asegurarse de que la compilación funcione en el servidor de compilación. Para ello, debe asegurarse de que todo el software de requisito previo esté instalado en el servidor de compilación.

Para .Net, necesitamos instalar un componente llamado Visual Studio Redistributable package. Este paquete contiene todos los archivos necesarios que se requieren para un.Netaplicación para construir en un servidor. Así que llevemos a cabo los siguientes pasos de instalación en el servidor de compilación.

Step 4 - Haga doble clic en el archivo ejecutable para iniciar la instalación.

Step 5 - En el siguiente paso, acepte los Términos de la licencia y haga clic en Instalar.

Step 6 - Ahora, al ejecutar MSBuild, debemos asegurarnos de incluir un parámetro adicional al llamar a MSBuild que es - p:VisualStudioversion = 12.0. Esto garantiza que MSBuild haga referencia a los archivos que se descargaron en el paso anterior.

Ahora podemos ver que la solución se ha construido correctamente y también sabemos que nuestro proyecto de línea de base se construye correctamente en el servidor.

El siguiente aspecto clave es asegurarnos de que nuestro código de línea base esté registrado en nuestro servidor de administración de repositorio de código fuente, que es Git. Para hacer esto, debemos seguir estos pasos.

Step 1- Inicialice el repositorio para que pueda cargarse en Git. Esto se hace con elgitcomando init. Por lo tanto, debe ir a la carpeta de su proyecto y emitir elgit init mando.

Step 2- El siguiente paso se llama preparar archivos en Git. Esto prepara todos los archivos en la carpeta del proyecto, que deben agregarse a Git. Haces esto con elgit addcomando como se muestra en la siguiente captura de pantalla. Los '.' La notación se utiliza para decir que todos los archivos del directorio y subdirectorio deben incluirse en la confirmación.

Step 3 - El último paso es enviar los archivos al repositorio de Git, de modo que ahora sea un repositorio de Git completo.

Ahora que tenemos nuestro código fuente en el repositorio de Git y todo nuestro código inicial funciona en el servidor de compilación, es hora de crear un proyecto en nuestro servidor de integración continua. Esto se puede hacer mediante los siguientes pasos:

Step 1- Inicie sesión en el software TeamCity. Vaya a la URL de su servidor de integración continua -http://localhost:8080/login.html.

Ingrese las credenciales de administrador e inicie sesión en el servidor.

Step 2- Una vez que haya iniciado sesión, se le presentará la pantalla de inicio. Hacer clicCreate Project para iniciar un nuevo proyecto.

Step 3- Dé un nombre al proyecto y haga clic en Crear para iniciar el proyecto. En nuestro caso, le damos el nombre como 'Demo' a nuestro proyecto como se muestra en la siguiente captura de pantalla.

Step 4- El siguiente paso es mencionar el repositorio de Git que se utilizará en nuestro proyecto. Recuerde que en un entorno de integración continua, el servidor de CI debe recoger el código del repositorio habilitado para Git. Ya hemos habilitado nuestra carpeta de proyecto para que sea un repositorio habilitado para Git en el paso anterior. En TeamCity, debe crear una raíz VCS. Para esto, haga clic enVCS Roots en la pantalla principal del proyecto.

Step 5 - En la pantalla que aparece a continuación, haga clic en Create VCS root como se muestra en la siguiente captura de pantalla.

Step 6 - En la siguiente pantalla que aparece, realice los siguientes pasos -

  • Mencione el tipo de VCS como Git.

  • Asigne un nombre a la raíz de VCS, que puede ser cualquier nombre descriptivo. Hemos dado el nombre comoApp.

  • Proporcione la URL de búsqueda como C:\Demo\Simple - Esto es out git repositorio habilitado.

  • Si se desplaza hacia abajo en la pantalla, obtendrá un botón Probar conexión. Haga clic en él para asegurarse de que puede conectarse correctamente al repositorio habilitado para Git.

Step 7 - Haga clic en Crear y ahora verá su repositorio registrado como se muestra en la siguiente imagen.

Step 8- El siguiente paso es crear una configuración de construcción que se utilizará para construir el proyecto. Ve a la pantalla de tu proyecto enTeamCity → General Settings. Haga clic en Crear configuración de compilación.

Step 9- En la siguiente pantalla, asigne un nombre a la configuración de compilación. En nuestro caso lo hemos nombrado comoDemoBuild y luego haga clic en Crear.

Step 10 - En la siguiente pantalla que aparece, se le pedirá que elija el VCS repositoryque se creó en los pasos anteriores. Así que elige el nombre‘App’ y haga clic en Adjuntar.

Step 11- Ahora, en la siguiente pantalla que aparece, debemos configurar los pasos de compilación. Así que haz clic en el 'configure build steps manually' Hipervínculo.

Step 12 - En la siguiente pantalla de compilación, debemos ingresar los siguientes detalles -

  • Elija el tipo de corredor como MSBuild.

  • Dé un nombre opcional para el nombre del paso.

  • Dé el nombre del archivo que necesita ser construido. Cuando especificamos MSbuild en las secciones anteriores, normalmente vemos que damos la opción deSimple.csproj. Es necesario especificar lo mismo aquí.

  • Elija la versión de MSBuild como 'Microsoft Build Tools 2013'.

  • Elegir el MSBuild ToolsVersion como 12.0.

  • Desplácese hacia abajo en la página para Guardar la configuración.

Step 13 - En la siguiente pantalla, haga clic en Ejecutar.

Verá la compilación de su aplicación ahora en progreso.

Debería obtener una pantalla exitosa, lo cual es una buena señal de que su solución se está construyendo correctamente.

También puede ir a su registro de compilación para ver todos los pasos cubiertos por el servidor de Integración Continua como se muestra en la siguiente captura de pantalla.

Ahora que tenemos nuestro código base en Git y un enlace al servidor de Integración Continua, finalmente es hora de ver el primer paso de Integración Continua en acción. Esto se hace mediante la definición de tareas en el servidor de Integración Continua, como los desencadenantes, lo que hace que todo el Proceso de Integración Continua sea lo más fluido posible. Hagamos un cambio en nuestro código en Visual Studio.

Step 1 - Ir al Demo.aspx página en Visual Studio y realice un cambio en el título de la página.

Step 2 - Si consultamos nuestro repositorio de Git a través del git status comando, de hecho verá que el Demo.aspx El archivo ha sido modificado.

Ahora debemos asegurarnos de que cada cambio en nuestro código desencadene una compilación en nuestro servidor de integración continua. Para ello necesitamos hacer los siguientes cambios.

Step 3 - Vaya al panel de control de su proyecto y haga clic en la sección de activadores y haga clic en Add new trigger.

Step 4 - En la siguiente pantalla que aparece, elija VCS trigger, que se utilizará para crear un disparador de modo que cuando se realice un check-in en el repositorio, se active una compilación.

Step 5 - Click Show Advanced Options y asegúrese de que las opciones que se muestran en la siguiente captura de pantalla estén seleccionadas.

Step 6- Haga clic en Guardar. Ahora verá el activador registrado correctamente como se muestra en la siguiente captura de pantalla.

Step 7- Ahora es el momento de registrar nuestro código en el repositorio de Git y ver qué sucede. Así que vayamos a nuestro símbolo del sistema y emita elgit add comando para preparar nuestros archivos modificados.

Step 8 - Ahora emita el git commit comando, y enviará los cambios al repositorio de Git.

Step 9 - Si ahora va a la pantalla Descripción general de proyectos, verá que se ha activado y ejecutado una nueva compilación.

Si ves el Change log Tab, verá el git comment que desencadenó la construcción.

Intentémoslo una vez más. Hagamos otro cambio en elDemo.aspxarchivo. Realicemos ungit add comando y un git commit comando con el siguiente mensaje de confirmación.

Ahora verá que una compilación se activa automáticamente en el panel del proyecto en TeamCity.

La construcción mostrará un mensaje de éxito.

Ahora verá el mensaje de 'Segunda confirmación' que se utilizó cuando el cambio se comprometió a git repository.

Ahora hemos completado con éxito la primera parte del proceso de Integración Continua.

Una notificación de falla de construcción es un evento que se activa cada vez que falla una construcción. La notificación se envía a todas las personas clave cuando falla una compilación. Lo primero que debe hacer en tal caso es asegurarse de que se dedica tiempo a la compilación fallida para garantizar que la compilación se apruebe. Los siguientes pasos se utilizan para garantizar que las notificaciones de compilación se implementen en TeamCity.

Los siguientes son los pasos para configurar notificaciones por correo electrónico en TeamCity.

Step 1- En TeamCity, vaya al panel de su Proyecto, haga clic en Administración en la esquina superior derecha. Entonces verá elEmail Notifierenlace en el lado izquierdo. Haga clic en este enlace para que aparezca la configuración general del correo electrónico.

Step 2 - El siguiente paso es ingresar los detalles de una SMTP Server. Gmail proporciona una función SMTP gratuita, que puede ser utilizada por cualquier persona. Entonces podemos ingresar esos detalles en la siguiente pantalla que aparece como se muestra en la siguiente captura de pantalla.

  • Host SMTP: smtp.gmail.com
  • No de puerto SMTP - 465
  • Enviar mensajes de correo electrónico desde e inicio de sesión SMTP: debe ser una identificación de Gmail válida
  • Contraseña SMTP: contraseña válida para esa identificación de Gmail
  • Conexión segura: pon esto como SSL

Step 3 - Click Test Connectionsolo para asegurarse de que la configuración funcione correctamente. Luego haga clic enSave para guardar la configuración.

Step 4- El siguiente paso es habilitar las notificaciones de compilación para un usuario. La primera tarea es crear un usuario que reciba estas notificaciones de compilación. Vaya al panel de control de su proyecto y elija elUsers Option.

Step 5- Crea un nuevo usuario. Ingrese el nombre de usuario y la contraseña requeridos. Luego haga clic en el botón Crear usuario, que se ubicará en la parte inferior de la pantalla.

Step 6 - Ahora inicie sesión en el sistema TeamCity con esta nueva identificación de usuario y contraseña.

Step 7- Después de iniciar sesión, se le presentará la configuración general del usuario. En la sección Notificador de correo electrónico, haga clic en Editar.

Step 8 - En la siguiente pantalla que aparece, haga clic en Add new rule.

Step 9 - En Agregar nueva regla, elija las siguientes dos opciones y luego haga clic en Guardar.

  • Construye a partir de proyectos seleccionados: elija el proyecto de demostración.

  • Habilite la casilla de verificación para 'Error de compilación'.

Al habilitar estas dos opciones, ahora, cada vez que falla una compilación para el proyecto de demostración, se enviará una notificación por correo electrónico al usuario: demouser.

Step 10- Ahora activemos una compilación incorrecta para ver esto en acción. En Visual Studio, vaya a lademo.aspx.cs archivo y agregue una línea incorrecta de código.

Step 11 - Ahora verifique el código de Git haciendo un git add y git commit.

Ahora, en el Panel de control del proyecto, la compilación se activará automáticamente y verá que la compilación habría fallado como se muestra en la siguiente captura de pantalla.

Si inicia sesión en el ID de Gmail del demouser, en realidad verá una notificación de falla de compilación como se muestra en la siguiente captura de pantalla.

Uno de los aspectos clave de la Integración Continua es siempre ver cómo se están desempeñando las compilaciones, recopilar métricas importantes, documentar esos resultados y generar comentarios continuos a través de compilaciones continuas.

¿Cuáles son los beneficios de contar con estas métricas?

  • Not Committing Code Enough- Si los desarrolladores no envían código a un repositorio de control de versiones con frecuencia, la razón puede ser una compilación de integración lenta. Para comenzar a reducir la duración de la compilación, realice un análisis de alto nivel del entorno de compilación de integración para determinar los cuellos de botella.

    A continuación, analice los hallazgos y determine la mejora más adecuada, luego intente realizar cambios en el proceso de construcción para reducir la duración de la construcción. Por último, reevalúe la duración de la construcción para determinar si se justifican más mejoras.

  • Improve Test Performance- Incluso en un sistema de CI que funcione bien, la mayor parte del tiempo de construcción de la integración se ocupará de la ejecución de pruebas automatizadas. Evaluar y mejorar el rendimiento de estas pruebas puede reducir drásticamente la duración de la compilación.

  • Infrastructure Issues- Puede descubrir que las compilaciones de integración son lentas debido a la infraestructura del sistema. Quizás el rendimiento de la red es lento o hay una conexión de red privada virtual de rendimiento lento.

    Los sistemas geográficamente dispersos y el hardware o software poco fiables también pueden provocar problemas de rendimiento. Investigue y mejore los recursos de infraestructura para reducir la duración de la construcción.

Métrica

A continuación, se muestran algunas de las métricas que están disponibles en un servidor de integración continua.

Veamos lo que TeamCity tiene para ofrecer:

Una de las formas más simples de métricas es la que está disponible en el panel del proyecto. El elemento clave aquí es anotar la duración de cada construcción. Si la duración de cada compilación comienza a aumentar de manera desproporcionada con respecto al código que se está compilando, esto podría ser un problema. Por lo tanto, esta es una retroalimentación que se puede tomar y las causas de esto podrían ser que el servidor CI tiene pocos recursos y tal vez la capacidad del servidor deba aumentarse.

TeamCity tiene la capacidad de ver si el servidor CI tiene algún tipo de problema con respecto a la infraestructura. En eladmin dashboard en TeamCity, se puede hacer clic en Disk Usage para ver cuánto espacio en disco consume cada compilación.

Si se requieren más detalles, TeamCity tiene la diagnostics button, que puede brindar más información sobre CPU and Memory siendo utilizado por el servidor CI.

Vista detallada de métricas de compilación

Si uno quiere ver una vista detallada de las compilaciones de un proyecto en particular a lo largo del tiempo, entonces esto está disponible como parte de las compilaciones del proyecto. En la pantalla de construcción del proyecto, vaya a la pantalla de estadísticas, esto le proporcionará varias estadísticas y gráficos sobre el rendimiento de la construcción.

Una de las características clave de la integración continua es garantizar que el on-going testingcontiene todo el código que genera el servidor CI. Después de que el servidor CI lleva a cabo una compilación, debe asegurarse de que los casos de prueba estén en su lugar para que se pruebe el código requerido. Cada servidor de CI tiene la capacidad de ejecutar casos de prueba unitarios como parte delCI suite. En.Net, la prueba unitaria es una característica que está incorporada en el .Net framework y lo mismo se puede incorporar al servidor CI.

Este capítulo verá cómo podemos definir un caso de prueba en .Nety luego deje que nuestro servidor TeamCity ejecute este caso de prueba después de que se complete la compilación. Para ello, primero debemos asegurarnos de que tenemos una prueba unitaria definida para nuestro proyecto de muestra.

Para hacer esto, debemos seguir los pasos siguientes con sumo cuidado.

Step 1- Agreguemos una nueva clase a nuestra solución, que se utilizará en nuestra prueba unitaria. Esta clase tendrá una variable de nombre, que contendrá la cadena "Integración continua". Esta cadena se mostrará en la página web. Haga clic derecho en el Proyecto simple y elija la opción de menúAdd → Class.

Step 2 - Dar un nombre para la clase como Tutorial.cs y haga clic en el botón Agregar en la parte inferior de la pantalla.

Step 3- Abra el archivo Tutorial.cs y agregue el siguiente código en él. Este código simplemente crea una cadena llamadaName, y en el Constructor asigne el nombre a un valor de cadena como Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Hagamos el cambio a nuestro Demo.aspx.csarchivo para utilizar esta nueva clase. Actualice el código de este archivo con el siguiente código. Entonces, este código ahora creará una nueva instancia de la clase creada anteriormente.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - En nuestro demo.aspx archivo, ahora hagamos referencia al tp.Name variable, que fue creada en la aspx.cs archivo.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Solo para asegurarse de que nuestro código funcione bien con estos cambios, puede ejecutar el código en Visual Studio. Debería obtener el siguiente resultado una vez que se complete la compilación.

Step 6- Ahora es el momento de agregar nuestras pruebas unitarias al proyecto. Haga clic derecho enSolution y elige la opción de menú Add → New Project.

Step 7 - Navegar a Test y en el lado derecho, elija Unit Test Project. Dar un nombre comoDemoTest y luego haga clic en Aceptar.

Step 8 - En tu Demo Test project, debe agregar una referencia al proyecto Simple y a los testing assemblies. Haga clic derecho en el proyecto y elija la opción de menúAdd Reference.

Step 9 - En la siguiente pantalla que aparece, vaya a Proyectos, elija Simple Reference y haga clic en Aceptar.

Step 10 - Click Add Reference nuevamente, vaya a Ensamblajes y escriba Weben el cuadro de búsqueda. Luego agregue una referencia deSystem.Web.

Step 11 - En el Unit Test file, agregue el siguiente código. Este código asegurará que la clase Tutorial tenga una variable de nombre de cadena. También afirmará el hecho de que el Nombre debe ser igual a un valor de “Integración continua”. Este será nuestro sencillo caso de prueba.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Ahora ejecutemos nuestra prueba en Visual Studio para asegurarnos de que funciona. En Visual Studio, elija la opción de menúTest → Run → All Tests.

Después de ejecutar la prueba, verá que la prueba se ejecuta correctamente en el lado izquierdo de Visual Studio.

Habilitación de pruebas continuas dentro de TeamCity: ahora que todos los casos de prueba están en su lugar, es hora de integrarlos en nuestro servidor de Team City.

Step 13- Para esto, necesitamos crear un paso de compilación en la configuración de nuestro Proyecto. Vaya a la página de inicio de su proyecto y haga clic en Editar ajustes de configuración.

step 14 - Luego vaya a Paso de compilación → Compilación de MS y haga clic en Agregar paso de compilación como se muestra en la siguiente captura de pantalla.

En la siguiente pantalla que aparece, agregue los siguientes valores:

  • Elija el tipo de corredor como Pruebas de Visual Studio.

  • Ingrese un nombre de paso de prueba opcional.

  • Elija el tipo de motor de prueba como VSTest.

  • Elija la versión de Test Engine como VSTest2013.

  • En el nombre de los archivos de prueba, proporcione la ubicación como DemoTest\bin\Debug\DemoTest.dll - Recuerda eso DemoTestes el nombre de nuestro proyecto que contiene nuestras pruebas unitarias. losDemoTest.dll será generado por nuestro primer paso de construcción.

  • Haga clic en Guardar, que estará disponible al final de la pantalla.

Ahora tendrá 2 pasos de construcción para su proyecto. El primero es el paso de compilación que construirá el código de su aplicación y su proyecto de prueba. Y el siguiente se utilizará para ejecutar sus casos de prueba.

Step 15- Ahora es el momento de registrar todo su código en Git, para que se pueda activar todo el proceso de compilación. La única diferencia es que esta vez, debe ejecutar elgit add y git commit comando desde el Demo parent folder como se muestra en la siguiente captura de pantalla.

Ahora, cuando se active la compilación, verá una salida inicial que dirá que la prueba pasó.

Step 16 - Si hace clic en el resultado de Prueba aprobada y va a la pestaña Prueba, ahora verá que UnitTest1 se ejecutó y que se aprobó.

La inspección continua es el proceso de revisión de código automatizada de la inspección realizada para su código antes de que se ejecuten las pruebas reales. Existen diferencias sutiles entre la inspección y la prueba de software. Las pruebas son dinámicas y ejecutan el software para probar la funcionalidad. La inspección analiza el código basándose en un conjunto de reglas predefinidas.

Los inspectores (o las herramientas de análisis estáticas y dinámicas) están dirigidos por estándares identificados que los equipos deben cumplir (generalmente métricas de codificación o diseño). Los ejemplos de objetivos de inspección incluyen estándares de "gramática" de codificación, adherencia de capas arquitectónicas, duplicación de código y muchos otros.

La inspección continua reduce el tiempo entre un descubrimiento y una reparación. Hay varias herramientas de inspección continua disponibles. Para este ejemplo, usaremosNCover 3.xque tiene una integración con TeamCity. Veamos cómo podemos realizar la Inspección Continua y qué puede hacer por nosotros.

Descargue e instale NCover

NCover es un producto independiente que debe descargarse e instalarse. Para descargar NCover, haga clic en el siguiente enlace y descargue el instalador de 32 bits:http://www.ncover.com/info/download.

Ejecute el instalador descargado y luego haga clic en Siguiente después de que se inicie el instalador.

Acepte el acuerdo de licencia y luego haga clic en Siguiente.

Acepte los componentes predeterminados y haga clic en Siguiente.

Haga clic en el botón Instalar para comenzar la instalación.

Haga clic en el botón Finalizar para completar la instalación.

Inicie la instalación de NCover por primera vez yendo a C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Solo necesitará instalar una clave de prueba por primera vez, lo cual es un proceso sencillo.

Configurar el proyecto en TeamCity para usar NCover

Step 1 - Vaya a la pantalla de inicio de su proyecto y haga clic en Editar ajustes de configuración.

Step 2 - Vaya a Pasos de compilación y haga clic en Editar para TestStep. La inspección continua debe ejecutarse junto con las pruebas unitarias que se definen.

Step 3 - En la sección Cobertura .Net, haga clic en .Net Coverage Tool. Y luego elija la siguiente configuración.

  • Elija la herramienta .Net Coverage como NCover (3.x)
  • Plataforma como x86
  • Versión como v4.0
  • Ruta a NCover como C: \ Archivos de programa (x86) \ NCover
  • Deje las otras configuraciones como están

Step 4 - Haga clic en Guardar.

Step 5 - Ahora vaya a la pantalla principal de su proyecto y haga clic en Ejecutar.

Step 6- Una vez que se ejecuta la compilación, haga clic en Prueba aprobada. Ahora verá una pantalla de Cobertura de código y verá muchos indicadores métricos.

Step 7 - Ahora puede hacer clic en la pestaña Cobertura de código para obtener más información sobre el Análisis de código.

Step 8 - Haga clic en el fullcoveragereport.html. Ahora obtendrá un informe completo y completo sobre la inspección realizada para el.Net code.

La Integración Continua de la Base de Datos es el proceso de reconstruir su base de datos y los datos de prueba cada vez que se aplica un cambio al repositorio de control de versiones de un proyecto.

En Integración de bases de datos, generalmente todos los artefactos relacionados con la integración de bases de datos:

  • Debe residir en un sistema de control de versiones.
  • Puede probarse para verificar su rigor e inspeccionarse para verificar el cumplimiento de las políticas.
  • Se puede generar usando sus scripts de compilación.

Las actividades que pueden estar involucradas en la integración continua de bases de datos pueden ser cualquiera de las siguientes:

Drop a Database - Suelta la base de datos y elimina los datos asociados, para que puedas crear una nueva base de datos con el mismo nombre

Create a new Database - Cree una nueva base de datos utilizando el lenguaje de definición de datos (DDL).

Insert the Initial Data - Inserte cualquier dato inicial (por ejemplo, tablas de búsqueda) que se espera que su sistema contenga cuando se entregue.

Migrate Database and Data - Migre el esquema y los datos de la base de datos periódicamente (si está creando un sistema basado en una base de datos existente).

Modify Column Attributes - Modificar los atributos y las restricciones de las columnas de la tabla según los requisitos y la refactorización.

Modify Test Data - Modifique los datos de prueba según sea necesario para múltiples entornos.

Entonces, en nuestro ejemplo de base de datos continua, realizaremos los siguientes pasos:

  • Crearemos una base de datos de MS SQL Server y una tabla correspondiente.

  • Crearemos un script a partir de SQL Server Management Studio. Este script de base de datos se utilizará para configurar nuestra tabla en la base de datos.

  • Escribiremos un código en nuestro proyecto ASP.Net para acceder a esta base de datos.

  • Crearemos un paso en nuestro proyecto en TeamCity para ejecutar este script.

  • Revisaremos nuestro script en Git.

Pasos para hacer esto en la base de datos de AWS que se creó en una sección anterior.

Step 1- Cree una base de datos de MS SQL Server y una tabla correspondiente. Abramos SQL Server Management Studio y creemos una base de datos y una tabla simples. Haga clic derecho en bases de datos y haga clic enNew Database.

Step 2 - Nómbrelo como Demodb y haga clic en Aceptar

Step 3 - En la nueva base de datos, haga clic derecho y cree una nueva tabla.

Step 4 - Puede agregar las columnas que desee a la tabla.

Step 5 - Guarde la tabla y asígnele el nombre Demotb.

Step 6 - Ahora haga clic derecho en la tabla y elija la opción de menú Script Table as → Drop and Create to → File.

Step 7 - Guarde el archivo en la carpeta del proyecto de demostración como Sample.sql.

Así es como se vería el script de la base de datos. Primero eliminaría una tabla existente si estuviera presente y luego volvería a crear la tabla.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Ahora cambiemos rápidamente nuestro ASP.Net code para hacer referencia a la nueva base de datos.

Step 9 - En el Tutorial.cs archivo en su Demo project, agregue las siguientes líneas de código. Estas líneas de código se conectarán a su base de datos, tomarán la versión del servidor y almacenarán el nombre de la versión en la variable Nombre. Podemos mostrar esta variable de nombre en nuestroDemo.aspx.cs archivo a través de un Response.write mando.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Agregue el siguiente código al Demo.aspx.cs para asegurarse de que muestre la versión de SQL Server.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Ahora, si ejecutamos el código, obtendrá el siguiente resultado en el navegador.

Step 11- Ahora agreguemos nuestro paso en TeamCity que invocará el script de la base de datos. Vaya al panel de control de su proyecto y haga clic enEdit Configuration Settings.

Step 12 - Vaya a Pasos de compilación y haga clic en Add build step.

Elija las siguientes opciones (tenga en cuenta que el cliente MS SQL Server debe instalarse en el servidor CI).

  • El tipo de corredor debe ser la línea de comandos.

  • Dé un nombre de paso opcional.

  • La ejecución debe ser ejecutable con parámetros.

  • El ejecutable del comando debe ser C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

  • Los parámetros de comando deben ser -S WIN-50GP30FGO75 -i Sample.sql. Donde –S da el nombre de la instancia de SQL Server.

Step 13 - Haga clic en Guardar.

Ahora lo que se debe garantizar es el orden de construcción. Debe asegurarse de que el orden de construcción sea el siguiente.

Step 14 - Puede cambiar el orden de construcción eligiendo la opción para reordenar los pasos de construcción.

  • La configuración de la base de datos debe ser la primera, por lo que se utilizará para recrear su base de datos desde nueva.

  • Lo siguiente es la compilación de su aplicación.

  • Finalmente su configuración de prueba.

Step 15 - Ahora ejecuta el git add y git commit comando para que el Sample.sqlEl archivo está registrado en Git. Esto activará una compilación automáticamente. Y esta construcción debería pasar.

Ahora tiene un ciclo de compilación completo con un aspecto de integración continua de la base de datos también en su ciclo. En la siguiente sección, profundicemos en esto y veamos la implementación continua.

Ahora que ha hecho esto con un servidor SQL local, podemos repetir los mismos pasos para un AWS MS SQLServidor que se creó en una de las secciones anteriores. Para conectarse a Microsoft SQL Server, debe conectarse a través de la siguiente convención.

Step 16- Primero vea cuál es el nombre asignado a su instancia de base de datos en AWS. Cuando inicie sesión en AWS, vaya a la sección RDS en la sección de base de datos.

Step 17 - Haga clic en DB Instances en la siguiente pantalla que aparece.

step 18- Haga clic en su base de datos y anote el punto final. En la siguiente captura de pantalla, esdemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Ahora para conectarse a la base de datos desde SQL Server Management Studio, debe especificar la conexión como demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Tenga en cuenta la coma utilizada entre el nombre de la instancia y el número de puerto).

La siguiente captura de pantalla muestra una conexión exitosa a la base de datos.

Entonces puedes repetir todos los mismos pasos. losSqlcmd command será como sigue -

Este mismo comando se puede reemplazar en el paso de construcción de la base de datos en TeamCity. Cuando ejecuta elsqlcmd command, la tabla se creará automáticamente en su base de datos de SQL Server en AWS.

Compilaciones automatizadas y compilaciones repetibles. Pruebas automatizadas y pruebas repetibles. Categorías de prueba y frecuencias de prueba. Inspecciones continuas. Integración continua de bases de datos. Esta serie de tareas en la creación de un entorno de CI efectivo permite principalmente un beneficio clave: lanzar software de trabajo en cualquier momento, en cualquier entorno.

En nuestros capítulos anteriores, hemos logrado todos los siguientes segmentos:

  • Creó nuestro código.
  • Aseguré una construcción adecuada en TeamCity.
  • Creé un proceso de Integración de Base de Datos.
  • Pruebas realizadas con éxito.

Ahora lo único que queda es realizar un despliegue automatizado, para que todo nuestro proceso esté completo.

Para una implementación automatizada en nuestro caso, debemos seguir estos pasos:

  • En nuestro servidor de implementación, asegúrese de que IIS esté instalado.

  • Asegúrese de que el usuario de IIS tenga acceso a nuestra base de datos.

  • Cree un perfil de publicación que se utilizará para publicar el sitio cuando se cree.

  • Asegúrese de cambiar nuestro comando MSBuild para realizar una implementación automática.

  • Automatice TeamCity para realizar una publicación automática.

  • Hacer un git commit para asegurarse de que todos sus archivos estén en Git.

Step 1- Configure un servidor IIS local. Si tiene un servidor IIS local o remoto, se puede realizar la siguiente configuración para implementar nuestra aplicación. Siempre es una buena práctica ver si una implementación se puede realizar manualmente antes de hacerlo de forma automatizada.

Step 2 - En un servidor de Windows 2012, vaya a su Administrador del servidor y haga clic en Agregar roles y características.

Step 3 - Haga clic en Siguiente en la siguiente pantalla que aparece.

Step 4 - Elija la instalación basada en funciones o basada en funciones en la siguiente pantalla y haga clic en Siguiente.

Step 5 - Seleccione el servidor predeterminado y haga clic en Siguiente.

Step 6 - Elija la función del servidor web y haga clic en Siguiente.

Step 7 - En la siguiente pantalla que aparece, haga clic en Siguiente.

Step 8 - Haga clic en Siguiente nuevamente en la siguiente pantalla que aparece.

Step 9 - En la siguiente pantalla que aparece, haga clic en Siguiente.

Step 10 - En la pantalla final, puede hacer clic en el botón Instalar para instalar IIS.

Una vez que haya instalado IIS, puede abrirlo abriendo los Servicios de información de Internet.

Step 11 - Haga clic en Grupos de aplicaciones, verá un grupo con el nombre de DefaultAppPool. Esto debe tener acceso a SQL Server en el siguiente paso.

Step 12 - Si necesitamos conectar una aplicación ASP.Net a una aplicación MS SQL Server, tenemos que dar acceso al grupo de aplicaciones predeterminado a la instancia de SQL Server, para que pueda conectarse a nuestra Demodb base de datos.

Step 13- Abra SQL Server Management Studio. Vaya a Logins, haga clic con el botón derecho y elija la opción de menúNew Login.

En la siguiente pantalla, actualice los siguientes parámetros y haga clic en Aceptar.

  • Nombre de inicio de sesión como IIS APPPOOL \ DefaultAppPool.
  • Base de datos predeterminada: debe ser nuestra base de datos, que es demodb.

Step 14 - Creando un Publish Profile. El perfil de publicación se usa en Visual Studio para crear un paquete de implementación que luego se puede usar con MS Build y en cualquier servidor CI en consecuencia. Para hacer esto, desde Visual Studio, haga clic derecho en el proyecto y haga clic en la opción de menú Publicar

Step 15 - En la siguiente pantalla que aparece, elija crear un nuevo perfil de publicación, asígnele un nombre - DemoDeployment. Luego haga clic en el botón Siguiente.

En la siguiente pantalla que aparece, agregue los siguientes valores:

  • Elija el método de publicación como Web Deploy.
  • Ingrese el servidor como localhost.
  • Ingrese el nombre del sitio como Sitio web predeterminado / Demo.
  • Ponga la URL de destino como http://localhost/Demo

Luego haga clic en el botón Siguiente.

Step 16 - En la siguiente pantalla, haga clic en Siguiente.

Step 17 - En la pantalla final que aparece, haga clic en el botón Publicar.

Ahora si vas a la C:\Demo\Simple\Properties\PublishProfiles ubicación de su proyecto, verá una nueva publish profile xml filecreado. Este archivo de perfil de publicación tendrá todos los detalles necesarios para publicar su aplicación en el servidor IIS local.

Step 18- Ahora personalicemos nuestro comando MSBuild y usemos el perfil de publicación anterior y veamos qué sucede. En nuestro comando MSBuild, especificamos los siguientes parámetros:

  • Implementar en compilación es cierto: esto activará una implementación automática una vez que se complete una compilación exitosa.

  • Luego, mencionamos usar el perfil de publicación que se usó en el paso anterior.

  • La versión de Visual Studio solo debe mencionarse en la capacidad de implementación de MSBuild sobre cuál es la versión de Visual Studio que se está utilizando.

Cuando ejecuta el comando anterior, MSBuild activará un proceso de compilación e implementación. Lo que notará es que lo está implementando en nuestroDefault Website en nuestro servidor IIS.

Ahora, si navegamos hasta el sitio: http://localhost/Demo/Demo.aspx veremos el siguiente resultado, lo que significa que MSBuild realizó una implementación exitosa en nuestro sitio web.

Step 19 - Automatización a través de TeamCity - Ahora es el momento de agregar una tarea a nuestro servidor TeamCity para usar automáticamente MSBuild para implementar nuestra aplicación, según los pasos mencionados anteriormente.

Step 20 - Vaya al panel de control de su proyecto y haga clic en Edit Configuration Settings.

Step 21 - Vaya a Pasos de compilación y haga clic en Agregar un paso de compilación.

Elija las siguientes opciones:

  • El tipo de corredor debe ser MSBuild

  • Dar un nombre de paso opcional

  • Ingrese la ruta de construcción como Simple / Simple.csproj

  • Mantenga la versión de MSBuild como Microsoft Build Tools 2013

  • Mantenga la versión de MSBuild Tools como 12.0

  • Ponga la línea de comando como / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Step 22 - Haga clic en Guardar.

Asegúrese de que en los pasos de compilación, el paso Implementar sea el último paso de la cadena.

Step 23 - Ahora hagamos una final git commit, para asegurarse de que todos los archivos estén en Git y puedan ser utilizados por TeamCity.

Felicitaciones, ha configurado con éxito un ciclo de integración continuo completo para su aplicación, que puede ejecutarse en cualquier momento.

Hagamos una revisión final de las mejores prácticas de Integración Continua en base a todas las lecciones que hemos aprendido hasta ahora:

  • Maintain a code repository- Este es el paso más básico. En todos nuestros ejemplos, todo se mantiene en un repositorio de Git desde la base del código hasta los perfiles de publicación y los scripts de la base de datos. Siempre debe asegurarse de que todo se mantenga en el repositorio de código.

  • Automate the build- Hemos visto cómo usar MSBuild para automatizar una compilación junto con el uso de un perfil de publicación. Este es nuevamente un paso clave en el proceso de Integración continuo.

  • Make the build self-testing - Asegúrese de que puede probar la compilación manteniendo los casos de prueba unitarios en su lugar y estos casos de prueba deben ser de tal manera que el servidor de integración continua pueda ejecutarlos.

  • Everyone commits to the baseline every day- Este es un principio clave de la integración continua. No tiene sentido quedarse hasta el final de todo el proceso para ver quién rompe la construcción.

  • Every commit (to baseline) should be built- Cada compromiso realizado con la aplicación debe construirse correctamente. Si la compilación falla por cualquier motivo, entonces es necesario cambiar el código para garantizar que se apruebe.

  • Keep the build fast- Si la construcción es lenta, indicaría un problema en todo el proceso de Integración Continua. Asegúrese de que las compilaciones estén siempre limitadas a una duración, preferiblemente nunca deben exceder los 10 minutos.

  • Everyone can see the results of the latest build- El panel de TeamCity ofrece a todos una vista de todas las compilaciones, que se aprobaron o fallaron. Esto da una buena idea de todas las personas involucradas en el proceso de Integración Continua.