Cómo crear tu primera tubería CICD con dispositivos de Azure

1. Introducción: Hola y bienvenidos a este breve tutorial sobre cómo crear tu primer CRC de pipeline amigable ágil usando como tu DevOps. Mi nombre es cuando es agradable y he tenido suerte de trabajar con una serie de empresas tecnológicas así como agencias gubernamentales a lo largo de los años. Por un lado, me gustaría compartir mi propia experiencia y conocimientos a través de conferencias, publicaciones de blog, e incluso canales de YouTube. Pero basta de eso. Estas son las habilidades en las que estamos gong para enfocarnos con este curso. Nos vamos a familiarizar con como sus DevOps y sus esquemas de licencias. Vamos a estar usando como tu get ripples con código de Visual Studio. Vamos a estar seguros en sus gets master branch o rama principal desde un empuje directo por solicitudes de importación forzadas, entonces vamos a ser Lincoln estas solicitudes polares con como sus tableros. Por lo que hacemos cumplir la colaboración entre los canales de miembro de su equipo de plan etapa del ciclo. Después vamos a implementar una aplicación web para hospedar un sitio web con dos ranuras de implementación, una vida y una sorda, utilizando como sus plantillas PowerShell y una ARM, entonces vamos a estar creando una construcción de integración continua canalización para probar tu aplicación web antes de la implementación, que maneja la creación y verificación. Vamos a ser Lincoln como Build Pipeline donde liberan tubería entrega continua para desplegar a la ranura de profundidad, se detuvo para su aprobación manual, y luego desplegar para vivir una vez aprobado, que maneja el paquete y etapas de liberación del ciclo. Básicamente después de esto, creo que no solo tendrás las habilidades secretas que estás en canalización, sino que también manejarás un desarrollo completo en si quieres escribir para beneficiarte plenamente de este curso, necesitarás lo siguiente. Necesita estar familiarizado con como sus conceptos de nube y desarrollo. Entonces, por ejemplo, necesitas conocer tu IS desde tu pase. Necesitas saber cómo trabajar con repositorios de Git. Necesitas tener un activo como tu suscripción. Y esto puede ser acuerdos empresariales de pago por uso o incluso una prueba gratuita usando tus créditos. Los adeudos son tarjeta de prepago, y eso te dará $200.170 Euros créditos. Es necesario tener instalado Visual Studio Code o cualquier IDE capaz de trabajar con control de fuente basado en kit. También necesitas tener, como tus módulos PowerShell instalados. Y esto puede funcionar con Windows o Linux. Sí, funciona. No obstante, si no te sientes cómodo con eso, puedes usarlo como tu CloudShell. Por último pero no menos importante, Tómelo con calma. Siéntete libre de saltar adelante y seguir lo que te interesa. No obstante, podríamos perdernos algunos consejos y trucos. Si no sigues el curso ha tenido la intención de hacerlo. No te sientas intimidado si tienes algún problema, si te quedas atascado en cualquier parte, por favor no dudes en ponerte en contacto conmigo y haré todo lo posible para responderte. Pongámonos a trabajar y espero con ansias lo que se te ocurre. 2. Crea tu proyecto de DevOps de Azure: De acuerdo, entonces lo primero y lo que necesitaba hacer es apuntarme con su celo DevOps. Ahora podemos usar tus cuentas normales de Microsoft o puedes iniciar sesión con tu cuenta de GitHub. Entonces tengo que empezar gratis y crear una nueva cuenta de Microsoft. Por lo que ahora podemos elegir la región en la que vamos a iniciar nuestra cuenta de DevOps. Podemos darle un nombre a la organización y también podemos elegir como su centro de datos y cuál estaremos hospedando nuestro proyecto, lo cual es muy importante porque no tiene sentido trabajar en Europa Occidental y tener su repositorio en Brasil, para ejemplo. Ahora podemos crear un proyecto para empezar. Y lo que hay que señalar aquí es que podemos tener múltiples proyectos bajo una sola organización, y cada proyecto puede tener sus propios permisos y repositorios. Está bien, así que aquí puedes elegir si quieres que sea un proyecto privado o uno público. Entonces, ¿tienes la intención de trabajar en esta relación con el equipo y no tienes la intención de publicar nada, bien puedes simplemente elegir un privado. Entonces voy a usar una opción privada por ahora, voy a darle un curso de nombre de proyecto DevOps, y dar clic en crear proyecto. Por lo que en la página de resumen, podemos agregar una descripción sobre el proyecto. Podemos simplemente añadir una descripción por aquí. O podemos vincularlo al archivo Read Me o wiki en el repositorio. También tenemos las estadísticas del proyecto, lo que nos da una visión general de los ítems creados donde los tritones terminaron en los tableros. También obtenemos una vista sobre las solicitudes generales abiertas, los commits, y cuando empecemos a tener ductos también obtendrán estados en los ductos que han concluido con éxito, fallado, y así sucesivamente. También consiguió una lista de los integrantes por aquí. Y en la parte superior aquí podemos invitar a nuevos miembros. agregamos por correo electrónico. Y más básicamente va a suceder es que van a recibir una invitación por correo electrónico para unirse a esto como tu grupo de DevOps. También tenemos la sección de dashboard la cual tendrá más sentido a medida que obtenemos más contenido en este proyecto son la idea es que agreguemos widgets que estarán atados con elementos de trabajo, estados de despliegue, tiempo de entrega. También podemos agregar páginas web personalizadas, páginas rebajas, solicitudes de pull. Liberamos, liberamos ducto o reseñas y así sucesivamente, vamos y abajo aquí tenemos la página wiki para mí personalmente, me encanta documentar todo porque nunca sabes cuándo podrías cambiar departamento o podrías ir a otro lugar y alguien tendrá que hacerse cargo de lo que has estado manejando. O si tienes un nuevo miembro del equipo que necesita ponerse al día con todo. Por lo que usar el wiki por aquí es una buena manera de permitir que todos los miembros del equipo colaboren. Tenemos la capacidad de crear un wiki de proyecto principal y luego vincularlo con múltiples sub wikis. Como puedes ver aquí, haremos clic en crear wiki de proyecto. Nos dieron el título y luego podemos tener como una mini palabra tipo de editor de texto que se traducirá en Markdown. Ahora vamos a ver los ajustes de la organización y luego pasar a la sentencia del proyecto. 3. Ajustes de la organización y licencias: De acuerdo, así que antes que nada, vamos a volver a la organización. Y aquí vamos a bajar a la esquina inferior izquierda de la pantalla y dar click a organizaciones segundos. Aquí tenemos la capacidad de cambiar el nombre de la organización. Ya sea URL de privacidad, agregue una descripción, cambie la zona horaria, cambie al propietario y elimine toda la organización. Bajo eso conseguimos proyectos. Podemos agregar proyectos, podemos modificar proyectos, puedes agregar nuevos proyectos. Podemos renombrar o eliminar proyectos, y ahora llegamos a la sección de usuarios. Y esta sección es muy importante porque es aquí donde entran en juego las restricciones de licencia de SEO DevOps. Entonces si hago click en el resumen aquí, encontraremos que tenemos dos tipos de usuarios. Contamos con el usuario básico y el interesado. Ahora el interesado tiene acceso a un número limitado de características. Entonces, por ejemplo, el interesado puede administrar la organización. Puede acceder a tableros ágiles. Se puede acceder a una gestión ágil de portafolio. Y puede usar unas características estándar que incluye trabajar entre proyectos, paneles de Bu ver wikis, notificaciones personales gestionadas debido a la vista de resumen de pruebas elementos de trabajo, así como ver lanzamientos y administrar aprobaciones. Entonces como puedes ver, el Stakeholder sería más como tu manager o alguien que necesita aprobar las cosas en lugar de involucrarse realmente con las cosas técnicas de la nada. Y esto se puede asignar a unos usos limitados. Ahora el usuario básico te permite usar todas las características de Azure DevOps, con cada organización solo obtienes cinco usuarios gratuitos. El resto tendrás que pagar. No obstante, lo genial a tener en cuenta aquí es que si tienes suscriptores MST y o suscriptores empresariales de Visual Studio, puedes usarlos en lugar de una licencia básica. Por lo que no es necesario comprar ninguna licencia para ese tipo de usos. Por lo tanto, ten eso en cuenta. Ahora si hacemos click en el Buy, nos llevará de inmediato a la sección Benín. Podemos empezar establece una habilidad. Por lo que se puede decir que Berlín no se ha configurado ya eje de organización estará disponible hasta los límites de nivel libre. Entonces los límites del nivel libre lo son, y tenemos cinco acusadores del BCE. El resto tenemos que pagar. Tenemos 1800 minutos para los ductos CIC D alojados por Microsoft, que entraremos en un minuto. Y tenemos un auto alojado gratis ver tubería ICD con la libertad es que obtenemos 0 empleos paralelos pagados. Y eso significa que no podemos tener más de un ducto y ejecutarlos al mismo tiempo, ir y bajar a artefactos. Tenemos dos gigabytes libres de artefactos usados, menos de un uso de gigabyte emiten hasta dos gigabytes pruebas de carga libres basadas en la nube en las que podemos usar, tenemos hasta 20 mil espectadores. Para más información, puedes hacer clic en los límites de nivel gratuito. Y obtendrás Preguntas Frecuentes en el nivel gratuito. Pasando, tenemos la sección de auditoría. Entonces esto básicamente nos da un registro de cada actividad que ocurre en los proyectos, lo cual es bastante útil. Contamos con notificaciones globales. Por lo que estos nos permiten gestionar todas las notificaciones relacionadas con los proyectos. Aquí obtenemos un registro del uso de aplicaciones y extensiones por usuario. Tenemos extensiones si quieres agregar extensiones que se usen en un ducto, por ejemplo, también podemos asegurarlas para que no permitimos que las personas instalen extensiones también. Aquí, si hacemos clic en navegar por el mercado, podemos agregar diferentes extensiones. Puede agregarlos desde la configuración de la organización o desde la propia canalización pasando a como su Active Directory. Por lo que esta sección nos permite enlazar, ahí está su organización de DevOps con nuestro inquilino de Azure Active Directory. Por lo que está tu inquilino de Active Directory tendría a todos los usuarios de Active Directory sean usuarios híbridos de ITS o como usuarios de la nube. Y puedes agregarlas individualmente a Azure DevOps. Por lo tanto, en lugar de invitarlos con correos electrónicos, utilizaría en sus políticas de seguridad de cuentas de Active Directory. Podemos optar por permitir el acceso a aplicaciones de terceros utilizando OAuth. Por lo que permitiríamos que los desarrolladores utilizaran la API Vizio DevOps para hacer exactamente las mismas cosas que hacen en el portal, podemos optar por habilitar o deshabilitar la autenticación SSH. Podemos elegir por completo los proyectos públicos discapacitados, y podemos elegir si invitar o no a los usuarios de Github o bajar a Permisos. Estos son los permisos globales que aplicarían a la organización. Y cualquier profundidad de permiso que añadirías aquí se heredaría en los proyectos por debajo de él que tenemos ahora y el tablero nos permite elegir diferentes procesos para el como te compran en geometría usando el básico. Pero también podemos elegir específicamente ágil, scrum o CWR. Mi mudanza hacia abajo a ductos, tenemos piscinas de agentes y básicamente ductos alrededor con como sus DevOps Asians. Y estos agentes podrían ejecutarse en máquinas o contenedores. Ahora, como tú o te das un pool de agentes que puedes usar para ejecutar tus ductos. Pero también podrías crear tu propia piscina auto alojada. Y eso sería útil si quieres tener tuberías de automatización funcionando dentro de tu red privada. Entonces digamos que tienes un ducto que interactuaría con un servicio interno detrás de tu firewall corporativo. Y para eso puedes usar un agentes privados pueden tener ajustes, podemos deshabilitar Paxos anónimos, limitar las variables se pueden establecer en q tiempo. Nos meteremos en eso. con albercas de despliegue, trabajos paralelos. Ahora por supuesto, dado que estamos usando un nivel gratuito, no tenemos acceso a trabajos paralelos, pero sí tenemos la capacidad de comprar trabajos paralelos, como puedes ver a continuación, si vamos a ser utilizados en un proyecto privado se les permitió un trabajo paralelo, pero ese trabajo paralelo tiene que estar dentro de un auto alojado todo. Si nos vamos a utilizar en un pool asiático alojado en Microsoft, no tenemos caídas paralelas si el proyecto se va a publicar con un pool asiático alojado en Microsoft, se nos permiten diez trabajos paralelos si vamos a estar usando como auto hospedado paciente cálido, usando nuestras propias VMs u otros contenedores propios, tendríamos trabajos paralelos ilimitados. Por lo que vale la pena pensar. Aquí tenemos ambas configuraciones que nos permiten usar principios de servicio o cuentas de aplicaciones de otras fuentes como el servidor GitHub en la nube o GitHub Enterprise. Contamos con los repositorios donde podemos elegir activar o desactivar las imágenes de gravedad, podemos cambiar el nombre de la sucursal por defecto para nuevo repositorio. Por lo que en este momento por defecto, cada vez que creas un nuevo repositorio, obtendrías la sucursal principal. Tenemos artefactos. Podemos configurar el almacenamiento para artefactos. Y los artefactos son los archivos que estará publicando en su canalización de lanzamientos. Por el momento, tenemos 0 whew que fue muy largo ¿No era muy importante saber estos parece sobre todo si quieres usar como tu DevOps en producción, ahora pasaremos a la configuración del proyecto. 4. Ajustes de proyecto y conexión con Azure: De acuerdo, ahora hemos vuelto a nuestro proyecto, bajaremos a la esquina inferior izquierda de la pantalla y pincharemos en Configuración del proyecto. Aquí tenemos la capacidad de renombrar el proyecto en sí, la descripción. Podemos cambiar la visibilidad del proyecto dependiendo si tenemos o no habilitada la opción en la configuración de la organización. Si recuerdas esa, podemos tener administradores de proyectos y podemos habilitar o deshabilitar características. Aquí también podemos eliminar el proyecto, yendo a los equipos. Ahora por defecto, obtenemos un equipo creado con el proyecto. Y este equipo sería un grupo. Para que también puedas crear otro equipo. Y en este equipo se pueden sumar miembros y administradores. Y puedes usar esto para asignar permisos a todo un grupo. Entonces si vas a Permisos, tenemos los grupos predeterminados. Además del costo de DevOps que está aquí abajo, puede optar por usar un grupo predeterminado o puede crear sus propios grupos con permisos granulares. Personalmente me gusta tener permisos granulares. Por lo que puedo emplear al menos políticas privilegiadas. Por lo que podemos tener un administrador de proyectos justo en los tableros. Este podría ser el líder del equipo. El único que necesita mirar los elementos de trabajo es Scrum Sprints y así sucesivamente. Aquí tenemos las vistas de los grupos y de los usuarios. Por lo que todos los usuarios estarían apareciendo aquí. Si hacemos clic en el usuario, veríamos sus permisos ya que se heredan. También podemos ver los grupos de los que son miembros. Entonces, por ejemplo, la CSU texturizada forma parte del grupo de administradores de proyectos, equipo de cursos de DevOps y de los administradores de colección de proyectos de organización, e incluso de las notificaciones automáticas. Ahora por defecto, esto se enviará en cada evento como un correo electrónico al equipo del curso de DevOps. Puedes optar por mantenerlo así. Pero créeme, una vez que empieces a trabajar con las ondulaciones y publicado en ductos y todo eso, empezarás a recibir correos electrónicos muy spammy. Por lo que podría optar por desactivar algunos de ellos o crear una nueva suscripción con eventos específicos de ganchos de servicio es como la trama Notificaciones. Envía una notificación fuera de SEO DevOps. Por lo que si hago clic en Crear suscripción, podemos enviar eventos a una serie de servicios como el centro de aplicaciones como sus servidores de aplicaciones. Por lo que los eventos soportados llamados acciones apoyadas empujadas implementan una aplicación web, el almacenamiento de Service Bus. Podemos enviarle los Jenkins también. Entonces cuando se complete la construcción, podemos desencadenar una construcción sobre Jenkins. No tenemos que usar como tus DevOps, por ejemplo, podemos enviar algo a Office 365 por ejemplo. Entonces digamos que tienes un grupo de equipo, y cuando alguien crea un elemento de trabajo que enviará una notificación al puntaje del equipo, también podemos usar ganchos web. Entonces si tenemos nuestra propia API, podemos enviar eventos a esta API y procesarla en consecuencia. Entonces con los dashboards, podemos controlar quién puede crear, editar entidad, ellos. Bajando a tableros, teníamos la configuración del proyecto. Podemos establecer iteraciones altas. Podemos establecer datos, podemos agregar áreas que también podemos hacer desde la propia sección de la Junta. Contamos con la configuración del equipo donde podemos establecer los niveles de navegación. También podemos fijar los días hábiles para que el equipo estuviera trabajando oficialmente sólo de lunes a viernes. Podemos ir a iteraciones. Podemos ir a zonas donde podemos crear diferentes áreas. Por lo que aquí podemos establecer plantillas cuando alguien quiera publicar un número, cualquier pico o una tarea. Aquí tenemos conexiones GitHub. Aquí es donde seríamos Lincoln el proyecto con una cuenta de GitHub. Aquí tenemos las piscinas asiáticas, que es exactamente igual que las piscinas asiáticas en la configuración de la organización, tenemos los trabajos paralelos, que de nuevo es como la configuración de la organización. Contamos con la configuración de tuberías que nos permitirá establecer políticas de retención para el ducto de artefactos o conferencias. Contamos con la sección de gestión de pruebas que nos permite gestionar la detección de pruebas escamosas. Tenemos la retención de liberación, que nos dará información sobre la política de retención para los lanzamientos. Y aquí hay una sección muy importante que son las conexiones de servicio. Ya que vamos a estar usando como tu para este curso para desplegar una aplicación web y actualizar la página web, tenemos que crear una conexión de servicio. Entonces esto crea uno ahora, así que voy a dar clic en Consulta conexión de servicio. Y aquí como pueden ver, podemos enlazar con una serie de servicios. Por lo que podemos vincularlo con como su clásico Azure Resource Manager Bitbucket Chef, anfitrión Docker, voy a elegir como su gestor de recursos. Ahora la opción más fácil sería usar Service Principal automático, que vincularía su cuenta actual como su cuenta de DevOps con las cuentas en la nube de Azure cuando la seleccione ya que sus DevOps lo intentarán ya que está conectado actualmente definidas si están vinculadas con alguna como sus credenciales de Cloud. Ahora como esta cuenta no está vinculada con un 0, tendremos que hacer las cosas manualmente. Por lo que voy a volver manual de principio de servicio y voy a vincularlo con como su nube. Y voy a usar un ID de suscripción que tengo con otra cuenta. Por lo que voy a añadir el nombre de la suscripción. Voy a añadir el nombre de mi suscripción, que es de mi canal hermana de YouTube. Y ahora voy a usar un id de principio de servicio Así que voy a volver a mi como cuentas tuyas. Y voy a ir a Azure Active Directory, registros de aplicaciones. Y voy a crear un nuevo registro y voy a llamarlo desarrolla episodio. Voy a usar un solo inquilino. El agua puede utilizar número de opciones. Puntero registrar esta cuenta. Ok, entonces ahora tengo una identificación de cliente y una identificación de inquilino. Por lo que voy a usar una identificación de cliente. Principal de servicio TI principio clave va a ser la contraseña o el secreto. Entonces tienen que volver aquí y voy a crear un secreto. Ahora, idealmente con secretos, los generarías en el registro de la aplicación y luego los almacenarías en un Azure Key Vault, por ejemplo, porque la madera ahí como tu llave volt, puedes canjear dinámicamente los secretos y cuando expira el secreto y es hora de cambiarlo, no necesitas volver a tus aplicaciones y cambiaste un manual que solo puedes cambiarlas desde el teclado porque todas tus aplicaciones se conectan a la tecla bóveda fue una prueba expira en un año. No nos molestó. Correcto. Entonces ahora tengo el valor. Yo sólo puedo tomar que informes la clave principal del servicio. Y regresamos y obtenemos nuestro ID de inquilino, que es el dominio Azure AD. Eso ya está hecho. Nosotros le damos un nombre. De acuerdo, entonces estamos bien para irnos. Puedo dar click en Verificar. Entonces ahora cuando hago clic en Verificar me dice que estoy prohibido de Lincoln cosas importantes cuando creas un principio de servicio que le das acceso en la suscripción o el grupo de recursos con el que quieres trabajar. Por lo que tengo que volver a mi suscripción, ir a Control de Acceso, alterar las asignaciones de roles para todas las asignaciones. Y le voy a dar contribuyente. Oops, episodio. Y seguro. Debería darle un acceso contribuyente en la suscripción el cual aplicará en todos los grupos de recursos. Golpéalo. Está bien, para que pueda ir a verificar de nuevo. Todo se ve bien. Por lo que ahora hemos establecido una conexión con el como su nube. Esta conexión nos permitirá crear aplicaciones web, crear máquinas virtuales, ingresar deseos de corazón de datos en la suscripción. Contamos con servicios de construcción XHTML. Si quieres tener una conexión, tenemos las ondulaciones. Por lo que aquí tenemos la configuración de los repositorios. Podemos agregar nuevos repositorios, o podemos navegar, renombrar, eliminar los existentes. Podemos cambiar la configuración para que el nombre de la rama por defecto, por ejemplo, podamos imponer un tamaño máximo de archivo y una longitud máxima de ruta de nombres reservados, por ejemplo. Y tenemos permisos, podemos establecer permisos en los propios repositorios. Tener permiso para crear sucursal, Crear repositorio, Gran etiqueta. De acuerdo con los grupos, tenemos el almacenamiento de artefactos también, y tenemos las retenciones de prueba para que podamos mantener las pruebas automatizadas son iones resultados en adjuntos durante 30 días y para carreras de prueba manuales, podemos mantener ellos por un año. Eso es todo. Entonces ahora, te lo prometo, vamos a empezar a meternos en las cosas buenas. 5. Configuración de el GIT Repo: De acuerdo, entonces finalmente vamos a llegar a hacer algún trabajo. Entonces, antes que nada, vamos a revisar los reportes. Vamos a ir a archivos y nos encontramos con que nuestros repositorios y él tiene un archivo Read Me y tiene una sucursal principal. Ahora bien, no puedo recalcar esto lo suficiente. No se quiere trabajar directamente con dominio o rama maestra. Si trabajas con un equipo o te unes a una empresa y comienzas a meterte con la sucursal principal, no durarás mucho. Entonces, ¿qué vamos a hacer? Vamos a proteger a la rama principal haciendo cumplir las solicitudes polares. Y esas solicitudes de pull se vincularán con la de la directiva. Entonces, en primer lugar, llegamos a sucursales, nos dieron dos más y llegamos a las políticas de sucursales. Y aquí es donde hacemos cumplir las solicitudes de pull. Por el bien de este curso, voy a tomar permitir que los peticionarios mejoren sus propios cambios suelen no permitirles eso. La siguiente opción Voy a habilitar esta comprobación para elementos de trabajo vinculados y lo voy a configurar como se requiera. Entonces, lo que hemos hecho, hemos protegido a la rama principal de ser empujados directamente al por qué hacer cumplir las solicitudes de pull. Y también hemos forzado la colaboración con el equipo. Entonces eso es un polar solicitudes no serán aprobadas a menos que esté vinculado con un ítem de trabajo. Entonces ahora si voy a publicar código, tendré que ramificarme, publicar un resfriado en la sucursal, presentar una solicitud de extracción que tiene que estar atada al elemento de trabajo y luego fusionarme. Entonces, en primer lugar, voy a ir a tableros elementos de trabajo, y voy a agregar un nuevo elemento de trabajo, una tarea que dice implementar sitios web. Me lo asignaré a mí mismo y añadiré esa lista de tareas pendientes. Ahora, el elemento de trabajo, podemos vincularlo a una razón específica, un área específica que podemos definir en los ajustes del proyecto. Y también podemos asignarlo a un sprint específico. Podemos vincularlo con ciertas ramas en la ondulación así como otros elementos de trabajo. Y en cuanto tengamos un lanzamiento vinculado con una solicitud de pull, empezaría a aparecer aquí. Además, bajo este rubro de trabajo, podemos agregar una descripción que animo a la gente a agregar. Entonces aquí hablaremos de esta nueva característica que le habían agregado, esta nueva corrección de errores y demás. También puedes tener una discusión donde otros miembros del equipo pueden agregar comentarios. Se puede ver el estatecraft y sus tres. Podrías vincularlo con otros artículos. Y también puedes agregar archivos adjuntos. Entonces por ahora voy a ahorrar y tenemos tarea número siete ahora para empujar este código que van a primero, clonar este informe a nuestro código de Visual Studio IDE. Y la forma más rápida de hacerlo es usar el botón de clon y hacer clic en el código de Visual Studio. Y lo que esto hace esencialmente es que crea un token de acceso personal, que puedes encontrar aquí, tokens de acceso personal. Creará un token de acceso personal en segundo plano que permitiría a su Código de Visual Studio iniciar sesión en Azure DevOps. Y hay que tener cuidado con esto porque cada vez que haga clic en este botón, estará creando un nuevo token de acceso personal. Entonces por ahora voy a abrir Visual Studio Code. Y vamos a usar este botón. Y ahora una extensión para abrir CRI, abierta ahora iba a preguntarnos dónde queremos almacenar nuestro nuevo REPL. Entonces démosle una nueva carpeta. Episodios de Devops. Y volquemos aquí dentro. Ahora son clones en tu repositorio de Git. ¿ Te gustaría abrir un clon? El repositorio diríamos Abrir, y ahora estamos conectados con nuestro repositorio en Azure DevOps. Entonces en esta etapa, lo que me gustaría que hicieras es a los gritos Brown. Por lo que vamos al control de fuentes, pinchamos en los tres botones y llegamos a pagar también. Diría primer borrador. Está bien. Y ahora me gustaría que descargaran el archivo zip para este curso, extraigan los archivos, y los volcaran en esta carpeta, ¿no? Por lo que ahora tenemos el archivo zip extraído en la carpeta, que está usando la primera rama de borrador. Y lo que esto básicamente es una sencilla aplicación web Node.js nosotros. También tenemos un archivo 0 desplegado o adyacente, que es una plantilla como tu gestor de recursos, plantilla ARM. De lo que esto hace, desplegará una granja de servidores con una aplicación web que tiene dos ranuras de implementación, viva en sordos. Y cada una de estas ranuras de despliegue tendrá su propia URL. Además de eso, si lo quieres investigar, hemos ingresado a tus ductos archivo YAML. Y para este curso estaremos utilizando la GUI clásica para que pueda acostumbrarse a desplegar estos ductos. No obstante, ten en cuenta que puedes usar estos archivos y almacenarlos en tu repositorio de códigos para el control de versiones. Entonces ahora tienes que empujarlo a nuestra primera rama de borrador. Ya hemos hecho los commits de portones, ahora vamos a empujarlo. No sucursal aguas arriba, Sí, entendido. Haga clic en Aceptar. Y eso está hecho. Ahora, intentemos meternos con la rama principal. Entonces si voy a la principal y trato de agregar algo al archivo léame. De acuerdo, entonces ese es un nuevo cambio. Si voy al control de fuente, tenía que git commit message testing, Control Enter. Y trato de empujar este cambio. ¿ Qué va a pasar con este error? Si abrimos el git log, veremos que no se permiten los empujes a través de esta rama. Debes usar una solicitud de pull para actualizar esta sucursal. Entonces como pueden ver, hemos impedido que la gente juegue con la rama principal. Ahora imagina que la sucursal principal sería tu actual sitio web en vivo. No quieres que la gente se esté metiendo con ellos. Ahora vamos a Azure DevOps. Y si refresco, conseguiremos este mensaje que dice que actualizaste primer borrador hace dos minutos. También podemos ir a tirar solicitudes y crear una nueva solicitud de encuesta y también obtendremos el mismo mensaje aquí. Por lo que si hago click en nuevas solicitudes polares, podemos elegir una sucursal. Por lo que primer borrador en principal. Y aquí podemos agregar un título y una descripción para la solicitud de pull. Entonces diré primero borradores, una descripción de esta nueva solicitud de encuesta o esta nueva característica, esta nueva corrección de errores y los revisores. Por lo que voy a añadir uno. Aquí. Tenemos que añadir un elemento de trabajo. Por lo que vamos a añadir los sitios web de despliegue. Y ahora tenemos una solicitud de pull que se quedará así hasta que alguien lo apruebe. Como puedes ver aquí, tenemos la visión general. Nos dice que más viejo bastante Shek tuvo éxito. Entonces, ¿qué pasará aquí? En primer lugar, quiero comprobar si hay un elemento de trabajo vinculado con él. En segundo lugar, se va a comprobar si hay un conflicto de fusión. Entonces si tienes algún conflicto de fusión y sabremos con mucha antelación de que eso suceda. Y claro que tendremos que arreglarlo. Y en esta etapa, si agregas más cambios a su primer borrador, automáticamente aparecerá con una solicitud pull si no ha sido aprobada como 50 para archivar, veremos todos los archivos que estamos agregando o cambiando las actualizaciones y se compromete. Entonces ahora ya que estoy tomando widgets uno, puedo aprobar y esto está hecho. Por lo que ahora podemos dar click en el botón Completar y una botella completa lo fusionará con dominio. También puede completar el elemento de trabajo asociado después de fusionarse. Por lo que aquí tienes la opción de ya sea completada o dejarla sin completar. Apenas en los casos el elemento de trabajo está empatado con múltiples solicitudes. Podemos hacer click en eso. También borraremos el primer borrador después de la fusión. Aquí también se puede agregar un mensaje de confirmación de fusión personalizado. Por lo que voy a completar la fusión. Eso se hizo el proyecto de recursos. Entonces ahora si voy a archivos y me llegó y encontraremos que tenemos nuestra nueva aplicación web. Si voy a mi código de Visual Studio a la rama principal y hago clic en pull. Deberíamos empezar a conseguir todos los archivos, como se puede ver aquí. Entonces ahora lo que hemos hecho, hemos vinculado nuestro repositorio con código de Visual Studio en nuestra propia laptop. Básicamente hemos creado un token de acceso personal que permitiría que los objetos visuales se decodificaran, iniciaran sesión en Azure DevOps, o bien hemos habilitado las solicitudes de extracción para que podamos proteger la sucursal principal de que alguien lo empuje directamente. Y tenemos solicitud de tirón empatado con tableros, por lo que hemos hecho cumplir la colaboración con el equipo. A continuación, nos vamos a centrar en crear nuestra aplicación web usando el archivo JSON de Azure deploy dot. Y luego vamos a pasar a crear una hora construir y liberar ductos. 6. Implementa la aplicación web con ARM: Ahora vamos a hacer algo de magia. Lo que me gustaría que hicieras es ejecutar PowerShell como admin y tipo Instalar módulo a Zen. Y esto va a descargar los módulos de Azure PowerShell, decir sí a todos, y continuar con la instalación. De acuerdo, una vez hecho eso, cierra esta sesión terminal y abre otra. Y ahora vamos a teclear la cuenta de connect a. Vamos a iniciar sesión usando nuestras credenciales para un 0, y eso es todo. Entonces lo primero que vamos a hacer es seleccionar nuestra suscripción. Entonces vamos a hacer suscripción ASR selecta y darle el nombre. Eso ya está hecho. Para implementar esta aplicación web, necesitamos tener un grupo de recursos. Entonces voy a escribir nuevos A's en el grupo de recursos. Nombre sería DevOps, ubicación del episodio sería y Europa Occidental. Y eso está hecho. Por lo que ahora podemos escribir view A's en implementaciones de grupos de recursos. Das el despliegue y apuntas episodio DevOps. Le damos el nombre del archivo de plantilla. Por lo que escribimos plantilla o archivo de plantilla y decimos, ya que eres diploide o JSON. Ahora como tenemos dos parámetros definidos en el archivo, podemos utilizarlos como parámetros de PowerShell. Entonces sitio, nombre de host lo llamaría tomar buena Sue, App, App, Nombre del plan de servicio. Nosotros lo llamaríamos tomar Egipto pronto. App, SBC p, k. nombre del grupo de recursos sería episodio DevOps. Hagamos verbosos. Ahí vamos. Plantilla es válida, por lo que tuvimos algún problema a plantilla, se detendría entonces bajo estado de comprobación y despliegue. Y entonces lo que podemos hacer, podemos ir a 0 y podemos averiguar que nuestro despliegue falló. ¿ Por qué? Así que díganos que la textura del nombre del host para subrayar la aplicación no es válida, obviamente porque la va a utilizar para una URL. Entonces volvamos a nuestros despliegues, que también fallaron, fallaron como podemos ver aquí. Y vamos a utilizar guiones plantilla tan válida como ir otra vez, refrescar. Ahora está diciendo desplegar esto, echa un vistazo. Entonces tenemos una granja de servidores y eso está hecho. Verificamos Visual Studio Code, exitoso. Entonces si vamos al grupo de recursos, encontraremos dos planes de servicio de aplicaciones y uno de servidores de aplicaciones. Si revisamos nuestros servidores de aplicaciones y vamos a las ranuras de implementación, encontraremos dos ranuras de implementación. Uno que se llama coger porquería. Entonces App para la producción y toma jujitsu dash app, dash dev para el desarrollo. A ahora la idea es que vamos a desplegar al desarrollo primero. Vamos a probar el sitio web es si se ve bien. Y luego vamos a cambiar las ranuras de despliegue a la producción. Entonces vayamos a resumen y revisemos la URL. Y como puedes ver, tenemos el marcador de posición Node JS para Microsoft o 0. Ahora podemos empezar a trabajar en nuestro Build Pipeline. 7. Integración continua de construir el pelucio: De acuerdo, de vuelta a nuestros productos DevOps. Nosotros vamos a ir a ductos y vamos a crear un ducto. tanto que tu código, así que tenemos una serie de opciones aquí donde podemos usar un zoológico ondulaciones, Bitbucket, consigue hub, y así sucesivamente. Por lo que vamos a elegir a medida que se pongan sus repositorios, no elegimos nuestro repositorio y esto recoge automáticamente el botón de archivo YAML canalizaciones de Azure en lugar de eso. Entonces vamos a volver y usar el editor clásico. Y aquí tenemos las mismas opciones con los proyectos de equipo y repositorios. Podemos elegir la rama principal y dar click en continuar. Ahora podemos elegir una plantilla si queremos, tenemos una serie de plantillas. Por ahora voy a elegir un trabajo vacío. Y aquí tenemos nuestro primer gasoducto de construcción. Vamos a darle un nombre aquí. Vamos a elegir la piscina asiática. Y como les dije, los ductos corren en el sudeste asiático de Asia serían en máquinas virtuales o contenedores. Estos agentes también pueden ser como sus agentes de canalización o puede haber asiáticos privados dentro de sus propias máquinas virtuales. Entonces vamos a usar eso a medida que sus ductos jalan. Y de esa alberca podemos elegir una serie de especificaciones. Entonces voy a elegir por B12 18 cuando llegó a la opción get Sources, sin pasos. Tienes la capacidad de cambiar de ramas. Por lo que si quieres probar este ducto en otra rama, puedes cambiarlo fácilmente aquí si está disponible. Pasando, vamos al trabajo asiático uno. Entonces aquí es donde empezamos a encabezar las tareas para el ducto. Entonces da click en el botón más aquí y tenemos una serie de tareas que podemos sumar. Entonces la primera tarea que vamos a agregar es probar la aplicación web y vamos a instalar npm. Aquí. Estamos buscando el trabajo y carpeta que contiene package.json, que es este archivo de aquí. Vamos a añadir una prueba de NPM, que no tenemos por aquí. Entonces lo que vamos a hacer, vamos a usar Command Line, que nos permite usar ya sea la línea de comandos en Windows o bash en Linux. Eso lo agregamos aquí. Y podemos decir, sí. Y pasó a escribir pruebas npm. También puede ir a Avanzado y asegurarse de que estamos usando el directorio de trabajo correcto. Debería ser a DevOps curso obviamente. Entonces, está bien, entonces ahora vamos a agregar archivo. Entonces vamos a archivar todos los archivos del sitio web. Voy a elegir una carpeta raíz. Por lo que vamos a utilizar el directorio de trabajo predeterminado del sistema variable. Vamos a eliminar antepuestos carpeta raíz, y queremos archivar como zip. Y vamos a utilizar las actualizaciones construidas de Arafat, directorio de la estación de artefacto construye ID. Ahora vamos a publicar esta aplicación web archivada para poder agregar otra tarea, artefactos de canalización publicados. Y entonces lo que va a pasar aquí es antes que nada, vamos a ejecutar la instalación de NPM. Entonces vamos a probar la aplicación web. Si la prueba tiene éxito, archivaremos y publicaremos la aplicación web. Por alguna razón la prueba falla. El ducto, el Build Pipeline se detendrá luego Ender, y por supuesto se te notificará al respecto. Ahora antes de continuar, vamos a tomar el archivo zip Build ID y añadirlo al artefacto de canalización publicado. Por lo que sólo publicamos el archivo zip. Entonces esto básicamente es el gasoducto de construcción. Entonces, ¿cómo podemos convertirlo en un ducto de integración continua? Íbamos a disparadores y garrapatas, Habilitar Integración Continua y lo vincularemos con la rama principal. Tenga en cuenta aquí que también podemos agregar filtros de ruta. Entonces eso es Podemos monitorizar una carpeta dentro de la rama principal en lugar de todo el asunto. Entonces eso está hecho y haga clic en guardar. Ahora antes de continuar, quiero mostrarles algo muy interesante, y esa es la sección Variables del ducto. Aquí, podemos agregar variables que se aplicarían al ducto. Estas variables pueden ser variables predeterminadas o tipo IQ configurable. Para que pudiera decir nombre de la computadora o nombre de la VM. Cuando se ejecute la tubería, esta variable se convertirá en una variable de entorno dentro de esta canalización. Y como quiero usarlo, puedo llamarlo así. Y obtendré el valor de esa variable si quisiera usarla en PowerShell, usaría la variable ENV uno. Si quería usarlo en Python, haré importar OS y OS dot environ. Dado que es un diccionario, diríamos variable, y eso nos daría el valor de esa variable para ser utilizada dentro del script. Por lo que estas variables pueden ser ya sea textos básicos seguros también. Para que puedas usar contraseñas o también puedes agregar una tarea antes de que se ejecute todo el asunto. Usó una bóveda de llaves. Nos vincularíamos con nuestra conexión y suscripción. Conseguiríamos el nombre secreto de la bóveda clave específica. Y eso se convierte también en una variable de tubería, que luego puedes usar. En consecuencia. Escribiríamos los nombres secretos del nombre secreto era secretos contraseña. Añadirías contraseña secreta aquí y la utilizarías dentro de la tubería. Para que no tengas que codificar contraseñas sensibles en ningún lugar. Simplemente puedes conectarte a Key Vault, poblar la variable y usarla. Bastante cool. Ahora, vamos a limpiar esto. De acuerdo, así que probemos nuestro Build Pipeline. Ahora como tenemos todo encerrado, tenemos que ir a tableros, elementos de trabajo ha creado un nuevo elemento de trabajo, pruebas, Construir, Pipeline, y asignármela a mí mismo. Ahorra frecuente. Eso se ve bien. Vamos a nuestro código de Visual Studio y vamos a ramificar primera característica. ¿ Verdad? Ir a, ir a vistas Índice. Y voy a añadir algo de texto. Y decir mesa. Eso no es texto como tabla en realidad, pero sí, agregamos una fila, tenía un yo. Y luego bajo eso y otra fila. Eso sí, sí, sí. Está bien. Cve, ¿verdad? Añadido tabla. Y empujemos eso al primer largometraje. Precioso trabajo Lee. De acuerdo, déjame ir a los archivos. Está bien. Crear una solicitud de pull en un enlace de tabla. Es para probar y construir aprobador IMD de tubería. Está bien, lo apruebo. Se. Looks Goode completo. ¿ ETF ahora eso se fusiona. Revisemos nuestro ducto. Como se puede ver, empezó a funcionar. Por lo que es instalar prueba de NPM a aplicación web. El test lo sucedió archiva y luego publica. Y a continuación vamos a trabajar en el gasoducto de liberación. 8. Pipeline de despliegue continuos: Por lo que ahora crearíamos una canalización de lanzamiento para una plantilla Voy a elegir como su implementación de servicio de aplicaciones se tragaría, Haga clic en Aplicar, dale un nombre de etapa. Desplegar a dev, ir a trabajos y tareas. Y aquí vemos que tenemos dos tareas. Implementar App, Servicio a ranura, Administrar App Service, Intercambio de ranura. Ahora como queremos desplegar a dev, tener una forma de aprobación manual y luego desplegar a la vida. Vamos a quitar el canje de ranura para el escenario ahora irá a ir a desplegarse hasta la muerte. Vamos a seleccionar la suscripción de Azure, que hemos definido con nuestra conexión de servidores. Vamos a seleccionar Aplicación Web en Linux. Vamos a seleccionar el nombre del servicio de la app que ya tenemos texturizado. Entonces vamos a seleccionar el grupo Recurso y la ranura, que va a ser sorda. Muy bien, seguro. Ahora se irá a volver al ducto y mirar los artefactos. Te vas a dar click en anuncios. Queremos elegir nuestro Build Pipeline, construir y probar. Y para la versión vamos a elegir la última versión. Por lo que cada vez que se lance la última versión del artefacto Build Pipeline, lo usaremos. Ahora. Vamos a hacer clic en este icono de aligeramiento para habilitar el despliegue continuo. Por lo que manejaremos el CI y el bote de CD para el contenido. Y tenemos dos opciones. O habilitamos despliegues continuos o lo vinculamos a la solicitud de extracción. Entonces voy a usar un disparador de CD y voy a agregar un filtro de sucursal. Significa que eso está hecho. De acuerdo, el siguiente paso voy a ejecutar clon. Y le voy a decir a la vida. Y antes de que esto se desencadene vamos a usar una condición previa al despliegue. Y lo que esto hace, nos permite usar la aprobación previa al despliegue. Vamos a sumar un aprobador y podemos sumar un tiempo de espera. Por lo que podemos decir tu tiempo fuera de 24 horas por ejemplo. Entonces lo que pasará aquí es que terminará con desplegarse a sordos y luego detener o aprobación manual durante 24 horas que las personas que se van a agregar a los aprobadores estarán recibiendo correos electrónicos, pidiéndoles que evalúen y aprobar. En esta etapa, vamos a la Vida y en lugar de usar implementar App Service para ranura, vamos a intercambiar babosas. Y para usar App Service administrar swaps lotes. Elija nuestra suscripción, nuestro App Service, nuestro grupo de recursos, y nuestra ranura de origen. Y aquí vamos a tick swap con producción y hacemos click en seguro. Y con eso, señoras y señores diputados, hemos terminado un ducto CI CD. Vamos a sacar los últimos cambios de Maine porque agregamos ductos, así que tenemos que tirar de esos cambios, ¿verdad? Checkout para publicar en vivo Jose, tu vida, bien. Y otra fila. Vida publicada. Siguiente empuja esta característica. Publicar vivo. No empujamos ninguna sucursal aguas arriba, sí, bien. Tienes que tirar peticiones. Tú lo actualizas, nueva vida. Está bien. Eso está empatado con una pieza de trabajo. Vamos a atarlo con un revisor. Conoce, fusionar conflictos. Vista Warner debe aprobar, aprobar, completa, y lejos vamos. ¿ Qué va a pasar ahora? Solicitudes de pull emergentes. Y ahora vamos a construir y probar el sitio web. A ver. De acuerdo, así se publica el artefacto, se finaliza y se hace el trabajo. Ahora si vamos a liberar, refrescarlo de nuevo, ya veremos haber liberado uno es echar un vistazo a esto. Aquí vamos, Qd, si desplegamos a agente de desarrollo que está listo para el trabajo y esto lo espera en progreso. Ahora se va a desplegar a la ranura de desarrollo o justo en que tuvo éxito que ver lo que hiciste. puede ver el despliegue usando zip deploy iniciado logs de implementación. Eso ya está hecho. Por lo que se ha desplegado a tech jiu-jitsu dash app. Entonces tomemos esa URL y la abriremos aquí. Como puedes ver, contamos con nuestra página web de desarrollo. Tenemos la imagen de los conteos. Tenemos la mesa por aquí. Se ve bien. Quienes Somos. Se pone en contacto. Como se puede ver. Se ve bien. Vete y vuelve al lanzamiento. Vemos que desplegar a la vida está pendiente de aprobación. Ahora esto debería enviarme un correo electrónico. Déjame revisar mi correo electrónico. Como podemos ver aquí, tenemos utrificación pidiendo aprobación. Una vez que estés contento con ese cambio, puedes hacer clic en Ver aprobación. click en aprobar, dar los comentarios. O puedes postergarlo para más adelante. Y eso activará automáticamente la otra etapa del gasoducto de liberación. Y esta etapa va a intercambiar el desarrollo con el despliegue de vida y el progreso. Intercambia sobre la vida, hecho. Vamos a revisar el registro que está hecho. Entonces ahora si vuelvo a la página web y me quito el sufijo sordo. Nuestro sitio web es la vida. Y con eso, señoras y señores, hemos desplegado nuestra primera integración continua, tubería de despliegue continuo utilizando como sus DevOps, espero que hayan disfrutado de este curso. Estoy muy emocionado de ver cómo progresas con ello. Si tienes alguna duda, algún comentario en absoluto, por favor no dudes en ponerte en contacto conmigo y haré todo lo posible para ayudarte todo lo mejor. Muchas gracias. Adiós. 9. Fin: Gracias por seguir el curso. Espero que lo hayan encontrado muy informativo y útil. Encontrarás todos los materiales del curso en la descripción del curso a continuación. Y de nuevo, si tienes algún problema, si te quedas atascado en cualquier parte, por favor no dudes en ponerte en contacto conmigo y haré todo lo posible para ayudarte. Gracias.