Corso intensivo in Dev for Ops?


10

Ho studiato a CompSci dove ci hanno insegnato principalmente Java, ma quello che ho imparato lì è che la mia passione sono i sistemi, quindi ho sempre lavorato sul lato operativo. Sono a mio agio con gli script, quindi non sto cercando un sito per insegnarmi Ruby, ma qualcosa per spiegare più in profondità cosa fanno gli sviluppatori tutto il giorno. Voglio capire meglio la cultura e il modo in cui digerisci il semplice numero di file nei tuoi progetti: gli intangibili.

Se oggi venissi a sapere che lunedì mi sarei trasferito in un team di sviluppo, cosa avrei voluto leggere questo fine settimana?


3
Comincerei a leggere il mio "contratto" ... anche se fosse solo se hai bisogno di ri-negoziare il tuo stipendio ... A parte questo, solo un fine settimana non è certo abbastanza per leggere qualcosa di rilevante, soprattutto perché non sembra sapere con quale tipo di "infrastruttura" lavorerai ... immagina che sia un mainframe che esegue tutti i tipi di istanze di zLinux ... con "z" come scorciatoia per zero tempi di inattività (non trascurabili). .. per mantenere gli aeroplani in aria ...
Pierre.Vriens

@ Pierre.Vriens, commento esilarante. State tranquilli, questo in realtà non sta accadendo o sarei impegnato con il mio account LinkedIn in questo momento, ma non credo che quel tipo di mossa sarebbe straordinaria in questi giorni. Alcune organizzazioni potrebbero davvero trarre vantaggio scambiando alcuni membri dello staff tra team di sviluppo e operazioni, e sono sicuro che alcune organizzazioni fanno proprio questo durante le unità per "implementare DevOps".
Stephen C,

Risposte:


8

Dal momento che hai etichettato questa domanda come "cultura", presumo che non ti interessi un'applicazione specifica, ma le domande più ampie del flusso di lavoro e della gestione.

Probabilmente inizierei con "The DevOps Handbook"; è una buona panoramica delle diverse cose da considerare, senza immergersi troppo in profondità.

Anche la "consegna continua" di Jez Humble viene spesso citata; Non ne ho ancora letto molto, ma copre i concetti di controllo del codice sorgente e automazione delle build.

Se stai iniziando ad entrare in applicazioni su larga scala (questo potrebbe essere troppo un presupposto), un altro buon libro è "The Practice of Cloud System Administration" di Limoncelli et al.


1
Ho letto circa il 60% del libro Limoncelli prima di perderlo in una mossa. Mi ha sicuramente insegnato molto. Ho anche appena iniziato "The Phoenix Project" di Gene Kim et al., Che è una lettura sorprendentemente avvincente mentre insegna anche molto.
Stephen C,

Mi è piaciuto anche il libro SRE di Google; è in realtà una soluzione migliore per me nella mia organizzazione rispetto ad alcune delle cose DevOps, ma il libro stesso è disgiunto. Devi leggerlo per ordine, scegliere i capitoli che ti interessano e scremare il resto.
Stuart Ainsworth,

7

Non si tratta di DevOps, ma di uno sviluppo software diretto, suppongo.

Voglio capire meglio la cultura

Bene, la cosa importante nello sviluppo diretto (senza l'angolo "DevOps") è certamente "agile", vale a dire per lo più SCRUM. Potresti fare di peggio che sederti e leggere il Manifesto Agile o un primer su SCRUM o Kanban per i lavori di manutenzione, correzione dei bug più quotidiani.

A parte questo, parlare di "cultura" è, proveniente dal lato sviluppo, principalmente una cosa specifica DevOps. Sì, abbiamo anche i nostri evangelisti, in particolare per cose più recenti come ruby ​​o golang, ma non così estreme come nel mondo DevOps / Cloud, dove ci sono cambiamenti di paradigma in corso.

e come digerisci il puro numero di file nei tuoi progetti

Avendo lavorato su applicazioni di rubino non banali, non è un problema. Vedi, quei file non sono solo sparpagliati, ma c'è una gerarchia, convenzioni e tutto il resto. In realtà non hai mai bisogno di avere tutti quei file nella tua testa in un unico punto nel tempo, per un progetto ben progettato. Se lavori in un'area specifica, di solito è abbastanza chiaro dove si trovano i file pertinenti e puoi ingrandirli abbastanza facilmente. Lo stesso dovrebbe valere per altri ambienti di programmazione moderni.

In cattive applicazioni, questo è diverso, ma poi lo sviluppatore non "digerisce" nulla, ma inciampa in una frenesia tutto il giorno fino a quando non si chiude. ;)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.