¿Curso intensivo en Dev para operaciones?

10

Estudié en CompSci donde principalmente nos enseñaron Java, pero lo que aprendí allí es que mi pasión son los sistemas, por lo que siempre he trabajado del lado de las operaciones. Soy hábil con las secuencias de comandos, así que no estoy buscando un sitio para enseñarme Ruby, sino algo que explique más a fondo lo que hacen los desarrolladores todo el día. Quiero comprender mejor la cultura y cómo digiere la gran cantidad de archivos en sus proyectos: los intangibles.

Si supiera hoy que me trasladarían a un equipo de desarrollo el lunes, ¿qué me gustaría leer este fin de semana?

— Stephen C
fuente

3

Comenzaría a leer mi "contrato" ... incluso si fuera solo si necesita renegociar su salario ... Aparte de eso, solo un fin de semana seguramente no es suficiente para leer nada relevante, especialmente porque no Parece que no sabe con qué tipo de "infraestructura" trabajará ... imagínese que es un mainframe que ejecuta todo tipo de instancias de zLinux ... con la "z" que es un atajo para un tiempo de inactividad cero (no negociable). .. para mantener los aviones en el aire ...

— Pierre.Vriens

@ Pierre.Vriens, comentario hilarante. Tenga la seguridad de que esto no está sucediendo realmente o estaría ocupado con mi cuenta de LinkedIn en este momento, pero no creo que ese tipo de movimiento sea extraordinario en estos días. Algunas organizaciones realmente podrían beneficiarse intercambiando algunos miembros del personal entre equipos de desarrollo y operaciones, y estoy seguro de que algunas organizaciones hacen exactamente eso durante las campañas para "implementar DevOps".

— Stephen C

8

Como ha etiquetado esta pregunta como "cultura", supongo que no está interesado en una aplicación específica, sino en las preguntas más amplias de flujo de trabajo y administración.

Probablemente comenzaría con "El manual de DevOps"; Es una buena visión general de las diferentes cosas a tener en cuenta, sin profundizar demasiado.

"Entrega continua" por Jez Humble también se hace referencia a menudo; Todavía no lo he leído mucho, pero cubre los conceptos de control de origen y automatización de compilaciones.

Si está comenzando a entrar en aplicaciones a escala (esto puede ser una suposición demasiado grande), otro buen libro es "La práctica de la administración del sistema en la nube" de Limoncelli et al.

— Stuart Ainsworth
fuente

1

Leí alrededor del 60% del libro de Limoncelli antes de perderlo en un movimiento. Definitivamente me enseñó mucho. También acabo de comenzar "The Phoenix Project" de Gene Kim et al., Que es una lectura sorprendentemente convincente mientras que también enseña mucho.

— Stephen C

También me gustó el libro de Google SRE; En realidad, es mejor para mí en mi organización que algunas de las cosas de DevOps, pero el libro en sí está desarticulado. Tienes que leerlo fuera de servicio, eligiendo los capítulos que te atraen y desglosando el resto.

— Stuart Ainsworth

7

No se trata de DevOps, sino del desarrollo de software directo, supongo.

Quiero entender mejor la cultura

Bueno, lo importante en el desarrollo directo (sin el ángulo "DevOps") es ciertamente "ágil", es decir, en su mayor parte SCRUM. Puede ser peor que sentarse y leer el Manifiesto Ágil o una cartilla sobre SCRUM, o Kanban para los trabajos más diarios, de corrección de errores y mantenimiento.

Aparte de eso, hablar de "cultura" es, desde el lado del desarrollador, principalmente una cosa específica de DevOps. Sí, también tenemos nuestros evangelistas, específicamente para cosas más nuevas como ruby o golang, pero no tan extremas como en el mundo DevOps / Cloud, donde están sucediendo cambios reales de paradigma.

y cómo digiere la gran cantidad de archivos en sus proyectos

Después de haber trabajado en aplicaciones de rubí no triviales, eso no es gran cosa. Verán, esos archivos no solo están esparcidos por todos lados, sino que hay una jerarquía, convenciones y todo eso. En realidad, nunca necesita tener todos esos archivos en su cabeza en un solo punto en el tiempo, para un proyecto bien diseñado. Si trabaja en un área específica, generalmente está bastante claro dónde están los archivos relevantes, y puede hacer zoom sobre ellos con bastante facilidad. Lo mismo debería aplicarse a otros entornos de programación modernos.

En las malas aplicaciones, eso es diferente, pero el desarrollador no "digiere" nada en realidad, sino que simplemente tropieza en un frenesí todo el día hasta que se rinde. ;)

— AnoE
fuente