Devops

¿Qué es DevOps?
DevOps es la unión entre Developers y Operations.
Históricamente estos equipos trabajan independientemente uno del otro.
Operadores vivían en bash y developers hacían producto en algún lenguaje sin saber qué hacían los operadores y vice-versa.
Eventualmente esta separación llegó a un tope donde no podía escalar más. Tanto developers y _operadores _empezaron a sentir frustración y empezaron a comunicarse, colaborar e integrarse unos con otros.
Como efecto secundario de dicha unión, las metas se alinean y el ciclo/proceso de desarrollo, prueba y deployment se vuelve más sencillo y corto.
¿Qué no es DevOps?
Una persona nueva en el equipo.
Una herramienta.
Un nuevo equipo.
Un unicornio mágico que hace que todo sepa a cerveza.
¿Qué es DevOps?
DevOps es un cambio en la cultura de los equipos y el deseo de mejorar sus procesos. Usualmente es orgánico.
El movimiento de DevOps promueve las siguientes iniciativas:
Cultura - el deseo en ambos equipos en colaborar.
Automatización - poder reproducir infraestructura como reproducimos bugs.
Medidas - saber cuánto tomaron nuestras metas en común.
Sharing - mejores herramientas internas compartidas por todos los equipos.
Como resultado de aprovechar las iniciativas de DevOps, muchos equipos han reportado que ven menos errores en producción, y cuando ven errores críticos logran revertir el daño con velocidad. Eso se convierte en Operadores que pueden dormir tranquilos, Developers que pueden seguir mejorando el producto y armonía entre todos en la empresa.



Éste es el flujo que debería tener un equipo que acepta DevOps:
Desarrollo -> Prueba -> Package -> Deploy (QA) -> Prueba -> Deploy (Prod) -> Monitor (repeat)
Cada equipo es diferente, pero la base seria relativamente igual.
Este proceso tiene muchos beneficios para equipos. Como los deploys son frecuentes, los cambios son pequeños.
Las pruebas disminuyen la posibilidad de errores. Si se nos escapa un deployment que contiene errores, el tiempo de recuperarnos es mucho más corto. Bug fixes salen en periodos más cortos. Lanzar nuevos features toma menos tiempo, lo que permite ajustes ágiles.

Continuous delivery:

-Se deben tener pruebas de unidad.
-Pruebas de integración.
-El CI debe estar corriendo pruebas de unidad e integración constantemente.
-Ambientes de QA para pruebas de aceptación.

Se deben implementar pruebas pues a medida que pasa el tiempo, el costo de reparar un defecto aumenta.

Como regla general se tiene que los defectos encontrados en producción tardan de 50 a 200 mas en corregir que si se hubiera encontrado en desarrollo.

Las pruebas Manuales tienen ventajas:

-Strange edge cases
-Aesthetics & design
-Overall user experience

Las pruebas se pueden clasificar en tres tipos y se ponen en una piramide, lo que quiere decir que son más empezando como se describe a continuación:

unit test: testing things in isolation - Rápidas, menos susceptibles y va subiendo en la pirámide
Integration: Testing things together
UI: user perspective

Unit testing or testing in isolation:

Se trata de probar cosas de manera aislada
Se centran en una clase a la vez
Se prueba la API pública, no probamos métodos privdos, solo el comportamiento que se expone

¿Para que son buenas las pruebas de unidad?

Probar el comportamiento detallado o la complejidad a bajo nivel.
Obtener defectos de regresión en el más bajo nivel.

¿Para que no son buenas las pruebas de unidad?
-Testing your class still works with its collaborators.
-Testing database access, services, file system, erc

Good practices

-Test boundary values: For numbers: Positive, negatives, greater, lower values, infinity
                       For strings : null string, empty, single character, new lines, unicode characters, ascci no imprimibles

-Write both positive and negative tests: a bad entry should produce an exception.
-High quality test code-
-Find a bug, write a test.
- test almost everything

Naming conventions:
-Test class:[name of class being tested]
-Test name:ShouldXXXX (behavior)
-Variable "SUT" SUT --> System under test


Buenas pruebas de unidad deben cumplir:
-Isolated from other tests )no shared state between tests)
-independent of run order (with other test)
-Repeatable /predictable outcome
-Tests a small/single/discreet behavior
-Helps document the system
-Valuable
-Executes quickly
-Readable --other developer can understand i/o, results
-maintainable
-Automated / non-interactive