Pausa para el café #120. Operadores Java &, && (Y) || (O). Introducción a GitOps y DevOps para desarrolladores

Operadores Java &, && (Y) || (O)

Fuente: freeCodeCamp En el lenguaje de programación Java, utilizamos operadores para realizar operaciones con variables. Los operadores se dividen en diferentes categorías: operadores aritméticos, operadores de asignación, operadores de comparación, operadores lógicos, etc. En este artículo, hablaremos sobre el operador AND bit a bit ( & ), así como sobre los operadores lógicos AND ( && ) y OR ( || ).

Cómo utilizar el operador AND bit a bit

El símbolo & denota el operador AND bit a bit. Evalúa el valor binario de números dados. El resultado binario de estos números nos será devuelto en base 10. Cuando el operador & comience a funcionar, evaluará el valor de los caracteres en ambos números, comenzando por la izquierda. Veamos un ejemplo para ayudar a entender esto mejor:

System.out.println(10 & 12);
// returns 8

¿Cómo explicar esto? El valor binario de 10 es 1010. El valor binario de 12 es 1100. Esto es lo que debemos considerar antes de comenzar la operación: 1 y 0 => 0 0 y 1 => 0 1 y 1 => 1 0 y 0 = > 0 Entonces hagamos la operación. El primer símbolo del 10 es 1, el primer símbolo del 12 también es 1, por lo tanto: 1 y 1 = 1. Pasando al segundo símbolo: 0 para el 10 y 1 para el 12: 1 y 0 = 0. Para el tercer símbolo - 1 para 10 y 0 para 12: 1 y 0 = 0. Para los cuartos caracteres - 0 para 10 y 0 para 12: 0 y 0 = 0. Ahora combinemos todos los caracteres devueltos. Esto nos da 1000. El valor binario de 1000 en base 10 es 8, por lo que nuestra operación devolvió 8.

Cómo utilizar el operador lógico AND

Tenga en cuenta que utilizamos operadores booleanos para evaluar las condiciones. Devuelven verdadero o falso según las condiciones dadas. El símbolo && representa el operador AND. Evalúa dos declaraciones/condiciones y devuelve verdadero solo si ambas declaraciones/condiciones son verdaderas. Así es como se ve su sintaxis:

statment1/condition1 && statemnt2/condition2

Como puede ver arriba, hay dos declaraciones/condiciones separadas por una declaración. El operador evalúa el valor de ambas declaraciones/condiciones y nos da el resultado: verdadero o falso . He aquí un ejemplo:

System.out.println((10 > 2) && (8 > 4));
//true

La operación devolverá verdadero porque ambas condiciones son verdaderas: 10 es mayor que 2 y 8 es mayor que 4. Si cualquiera de las condiciones tuviera una lógica incorrecta, recibiríamos falso . Para comprender mejor el operador && , debe saber que ambas condiciones deben ser verdaderas para evaluarse como verdaderas . Aquí hay otro ejemplo que devuelve falso :

System.out.println((2 > 10) && (8 > 4));
// false

Aquí 2 no es mayor que 10 y 8 es mayor que 4, por lo que obtenemos falso . Esto se debe a que una de las condiciones es incorrecta.

• Si ambas condiciones son verdaderas => verdadera

• Si una de las dos condiciones es falsa => falsa

• Si ambas condiciones son falsas => falsa

Cómo utilizar el operador booleano OR

Para indicar el operador OR utilizamos el símbolo || . Este operador devuelve falso sólo si ambas condiciones son falsas. Es decir, si ambas condiciones son verdaderas, seremos verdaderas , y si una de ambas condiciones es verdadera, entonces también seremos verdaderas . Aquí está la sintaxis:

statment1/condition1 || statemnt2/condition2

Veamos algunos ejemplos.

System.out.println((6 < 1) || (4 > 2));
// true

Se nos devuelve True porque una de las condiciones es verdadera.

• Si ambas condiciones son verdaderas => verdadera

• Si una de las condiciones es verdadera => verdadera

• Si ambas condiciones son falsas => falsa

Conclusión

En este artículo, aprendimos cómo utilizar el operador & bit a bit y los operadores lógicos && y || en Java. . También aprendimos qué valor devuelve cada operación según sus condiciones.

Introducción a GitOps y DevOps para desarrolladores

Fuente: Hackernoon Uno de los principales objetivos de DevOps es ayudar a los desarrolladores a implementar una función en producción de la forma más rápida y segura posible. Esto significa crear herramientas y procesos que hagan de todo, desde proporcionar entornos de desarrollo privados hasta implementar y proteger cargas de trabajo de producción. Al mismo tiempo, las prisas no deberían conducir a fallos críticos. GitOps es una forma de automatizar DevOps. Más específicamente, es una táctica de automatización que utiliza la herramienta de desarrollo Git. Dado que los desarrolladores ya envían código a un repositorio Git centralizado (usando algo como GitHub, GitLab o BitBucket), los desarrolladores de DevOps pueden conectar cualquiera de sus scripts de trabajo para crear, probar o implementar aplicaciones para ejecutar después de cada cambio de código. Esto significa que los desarrolladores pueden trabajar exclusivamente con Git y todo lo que les ayude a poner su código en producción estará automatizado.

¿Por qué GitOps?

Anteriormente, los métodos DevOps y CI/CD eran un conjunto de scripts y herramientas patentados que realizaban tareas cotidianas: ejecutar pruebas, aprovisionar infraestructura o implementar una aplicación. Sin embargo, la disponibilidad de nuevas herramientas de infraestructura como Kubernetes, junto con el aumento de las arquitecturas de microservicios, requiere que los desarrolladores se involucren más en los procesos de CI/CD. Este cambio creó problemas relacionados con los escenarios de los usuarios, lo que resultó en flujos de trabajo confusos e inconsistentes, duplicación de esfuerzos y una fuerte disminución en la velocidad de desarrollo. Para aprovechar las herramientas y arquitecturas de la nube, los equipos necesitan un enfoque consistente y automatizado para CI/CD. Esto permitirá a los desarrolladores:

• Deje de crear y mantener scripts propietarios y en su lugar utilice un proceso universal.

• Cree aplicaciones y servicios más rápido con un proceso de implementación universal específico.

• Implemente más rápido después de realizar cambios en el código.

• Habilite la implementación automatizada para lanzamientos más rápidos, frecuentes y confiables.

• Realice reversiones y auditorías para el cumplimiento de patrones de diseño declarativos.

A los desarrolladores les encanta GitOps

Por todas las razones expuestas anteriormente (y muchas más), las empresas necesitan enfoques gestionados y automatizados de CI/CD y DevOps para tener éxito en la creación y el mantenimiento de aplicaciones en la nube. Pero si lo único que hay que hacer es la automatización, entonces ¿por qué GitOps es mejor que otras estrategias (como SlackOps, implementaciones programadas o scripts simples)? La respuesta es simple: a los desarrolladores les encanta GitOps.

Git: una herramienta para gestionarlo todo

En los últimos años, ha quedado claro que GitOps es una de las estrategias de automatización de DevOps mejor valoradas entre los desarrolladores, y no es difícil ver por qué. Los desarrolladores viven en Git. Almacenan cambios temporales en git, colaboran usando git, revisan código usando git y mantienen un historial y un seguimiento de auditoría de cada cambio que alguien haya realizado, también en git. Debido a que los desarrolladores han llegado a depender tanto de git, existen herramientas especiales disponibles para trabajar con él. En los sistemas modernos de integración continua que se utilizan con mayor frecuencia para admitir GitOps, como CircleCI , Github Actions , Gitlab CI y otros, las configuraciones que admiten canalizaciones se encuentran directamente en el repositorio de Git. Al igual que el código fuente de la aplicación, estas configuraciones tienen control de versión y son visibles para todos los desarrolladores que trabajan en el proyecto. No solo pueden ver cuál es el proceso de canalización, sino que también pueden realizar cambios en él rápida y fácilmente según sea necesario. Esta facilidad de acceso para los desarrolladores es fundamental a medida que escriben pruebas para sus aplicaciones y garantizan su seguridad y estabilidad.

Autoservicio completo

Las nuevas funciones o correcciones de errores no se consideran completas hasta que se lanzan a producción. Esto significa que cualquier cosa que impida que se realicen cambios en el código en producción desperdicia tiempo y energía al desarrollador. Supongamos que un desarrollador tiene que esperar un tiempo a que otro equipo o persona complete alguna tarea antes de poder cerrar su paso de trabajo. Esto puede crear fricciones y conflictos en la organización. Facilitar la colaboración entre equipos es uno de los principales beneficios de GitOps. Los desarrolladores no solo tienen la oportunidad de trabajar con una herramienta familiar, sino que también pueden lanzar su código a producción sin intervención manual. Esto significa que no esperan a que otra persona complete sus tareas.

Trabajo continuo en todo.

¡Otro gran beneficio de GitOps es que todos los procesos están siempre ejecutándose! Cada cambio que realizamos desencadena compilaciones e implementaciones de prueba sin ningún paso manual. Dado que los desarrolladores usarán git con o sin GitOps, conectarse a su flujo de trabajo existente para ejecutar procesos DevOps es una opción ideal para la automatización.

GitOps en la práctica

Naturalmente, la participación de los desarrolladores en el proceso ha llevado a que los equipos hagan un uso generalizado de herramientas fáciles de usar como Git. Esto también crea una coherencia natural para las fases de integración/implementación de CI/CD. Después de todo, hay un número limitado de cosas disponibles en un repositorio de Git (por ejemplo, confirmaciones, solicitudes de extracción de apertura/cierre, fusiones, etc.), por lo que la apariencia de la mayoría de las implementaciones de GitOps implica un conjunto de pasos típicos:

1. Solicitudes de extracción, pruebas y entornos de vista previa

Después de que los desarrolladores han dedicado tiempo a escribir código para su nueva función, normalmente envían ese código a una nueva rama de Git y envían una solicitud de extracción o una solicitud de fusión a la rama principal del repositorio. Los desarrolladores hacen esto todos los días. El mensaje requiere que los gerentes técnicos revisen los cambios de código y los aprueben para fusionarlos en el código de la aplicación principal. Esta es una gran oportunidad para que DevOps agregue tareas adicionales. Al conectarse a los eventos de apertura/cierre generados por este proceso de solicitud de extracción mediante una herramienta de integración continua (CI), los equipos de DevOps pueden activar la ejecución de pruebas unitarias, la creación de entornos de vista previa y la ejecución de pruebas de integración en esos entornos. Esta herramienta permite a los ingenieros establecer rápidamente confianza en los cambios de código y permite a los gerentes de producto ver los cambios de código a través de un entorno de vista previa previa a la fusión. Una confianza más estrecha significa una fusión más rápida. Cuanto menos y más a menudo se ingresan los datos, menos retrocesos complejos y confusos. Esta técnica de GitOps es clave para equipos de desarrollo y producción más rápidos y saludables.

2. Fusionar con el maestro e implementar en la etapa de preparación.

Una vez que todas las partes hayan revisado los cambios, el código se puede fusionar en la rama maestra del repositorio junto con los cambios realizados por el resto del equipo de desarrollo. Esta rama maestra se utiliza a menudo como área de preparación para el código que está casi listo para producción. Todavía hay tiempo para completar algunas tareas operativas, como las pruebas y el despliegue. Si bien normalmente probamos el código para cada solicitud de extracción antes de fusionarlo, es una buena idea volver a ejecutar las pruebas para asegurarnos de que el código funcione con otros cambios realizados por el resto del equipo. También vale la pena implementar todos estos cambios en un entorno común (llamado "ensayo") que todo el equipo pueda usar para revisar y probar los últimos cambios antes de que se publiquen para los clientes.

3. Reducir los lanzamientos e implementar en producción.

Finalmente, después de que los gerentes e ingenieros hayan tenido tiempo de revisar y probar los últimos cambios en la rama ascendente, los equipos están listos para lanzar la versión e implementarla en producción. Esta tarea suele ser realizada por un administrador de versiones, un miembro del equipo dedicado (o rotativo) encargado de ejecutar scripts de implementación y monitorear la versión. Sin usar GitOps, este miembro del equipo debe verificar dónde están los scripts correctos, en qué orden ejecutarlos y si todas las bibliotecas y paquetes correctos necesarios para ejecutar los scripts están instalados en su máquina. Con GitOps, podemos vincular esta implementación a otro evento basado en Git: la creación de una versión o etiqueta. Todo lo que un administrador de versiones debe hacer es crear una nueva "versión", que a menudo usa semver como nombre. Las tareas para crear e implementar cambios de código se ejecutarán automáticamente. Como la mayoría de las tareas realizadas por una herramienta de CI, se configurarán con la ubicación de los scripts y el orden de las bibliotecas y paquetes necesarios para ejecutarlos.

Herramientas GitOps

Una herramienta de integración continua robusta e intuitiva no es lo único que se necesita para instrumentar procesos de GitOps como los que se describen en este artículo. Un sistema de CI puede activar scripts basados ​​en eventos de git, pero aún necesita herramientas potentes para ejecutar esos scripts y hacerlos fáciles y seguros de ejecutar y mantener. La implementación de cambios de código (también conocida como entrega continua, CD) es uno de los pasos más difíciles de automatizar. Es por eso que hemos seleccionado varias categorías de herramientas que pueden ayudarlo en su viaje a GitOps:

Contenedorización con Docker

Docker llevó el desarrollo de la nube a un entorno distribuido completamente nuevo y ayudó a los desarrolladores a comenzar a considerar de manera realista las arquitecturas de microservicios como una opción viable. Una de las cosas que hace que Docker sea tan poderoso es lo conveniente que resulta para los desarrolladores en comparación con las soluciones de virtualización de la generación anterior. Al igual que con las configuraciones de CI declarativas que se encuentran en nuestros repositorios, los desarrolladores simplemente necesitan escribir y mantener un Dockerfile en su repositorio para permitir compilaciones automatizadas de máquinas virtuales implementadas en contenedores. La contenedorización es una táctica extremadamente poderosa para los equipos de la nube y debería ser una herramienta central en su repertorio.

Infraestructura como código (IaC)

Se necesita mucho para preparar la infraestructura e implementar aplicaciones que no están almacenadas en un Dockerfile. Para todo lo demás, existen soluciones de infraestructura como código (IaC) como Terraform , Cloudformation y otras. Estas soluciones permiten a los desarrolladores describir otras partes de la aplicación, como los recursos de Kubernetes, los equilibradores de carga, las redes, la seguridad y más, de forma declarativa. Al igual que las configuraciones de CI y los Dockerfiles descritos anteriormente, las plantillas de IaC pueden controlarse en versión y compartirse entre todos los desarrolladores de su equipo.