Cours intensif dans Dev for Ops?

10

J'ai fait mes études à CompSci où nous apprenions principalement Java, mais ce que j'ai appris là-bas, c'est que ma passion est les systèmes, donc j'ai toujours travaillé du côté des opérations. Je suis à l'aise avec les scripts, donc je ne cherche pas un site pour m'apprendre Ruby, mais quelque chose pour expliquer plus en profondeur ce que vous faites les développeurs toute la journée. Je veux mieux comprendre la culture et comment vous digérez le grand nombre de fichiers dans vos projets - les actifs incorporels.

Si j'ai appris aujourd'hui que j'étais transféré dans une équipe de développement lundi, que voudrais-je lire ce week-end?

culture builds methodology software-engineering Stephen C
la source
3
Je commencerais à lire mon "contrat" ​​... même si ce n'est que si vous avez besoin de renégocier votre salaire ... En dehors de cela, un week-end n'est certainement pas suffisant pour lire quoi que ce soit de pertinent, surtout parce que vous ne ne semble pas savoir avec quel type d '"infrastructure" vous allez travailler ... imaginez que c'est un ordinateur central exécutant toutes sortes d'instances zLinux ... avec le "z" étant un raccourci pour zéro temps d'arrêt (non négociable). .. pour garder les avions en l'air ...
Pierre.Vriens
@ Pierre.Vriens, commentaire hilarant. Rassurez-vous, cela ne se produit pas ou je serais occupé avec mon compte LinkedIn en ce moment, mais je ne pense pas que ce genre de déménagement serait extraordinaire de nos jours. Certaines organisations pourraient vraiment bénéficier de l'échange de certains membres du personnel entre les équipes de développement et les opérations opérationnelles, et je suis sûr que certaines organisations le font lors des campagnes pour «implémenter DevOps».
Stephen C

Réponses:

8

Puisque vous avez marqué cette question comme "culture", je suppose que vous n'êtes pas intéressé par une application spécifique, mais par les questions plus larges du flux de travail et de la gestion.

Je commencerais probablement par "The DevOps Handbook"; c'est un bon aperçu des différentes choses à considérer, sans plonger trop profondément.

«Continuous Delivery» de Jez Humble est également souvent référencé; Je ne l'ai pas encore beaucoup lu, mais il couvre les concepts de contrôle de source et d'automatisation des builds.

Si vous commencez à vous lancer dans des applications à grande échelle (cela peut être trop une hypothèse), un autre bon livre est "The Practice of Cloud System Administration" de Limoncelli et al.

Stuart Ainsworth
la source
1
J'ai lu environ 60% du livre Limoncelli avant de le perdre d'un coup. Cela m'a définitivement beaucoup appris. Je viens également de commencer "The Phoenix Project" de Gene Kim et al., Qui est une lecture étonnamment convaincante tout en enseignant beaucoup.
Stephen C
J'ai aussi aimé le livre Google SRE; c'est en fait un meilleur ajustement pour moi dans mon organisation que certains des trucs DevOps, mais le livre lui-même est décousu. Vous devez le lire dans le désordre, choisir les chapitres qui vous plaisent et parcourir le reste.
Stuart Ainsworth
7

Il ne s'agit pas de DevOps, mais du développement logiciel direct, je suppose.

Je veux mieux comprendre la culture

Eh bien, la grande chose en développement droit (sans l'angle "DevOps") est certainement "agile", c'est-à-dire pour la plupart SCRUM. Vous pourriez faire pire que de vous asseoir et de lire le Manifeste Agile ou une introduction sur SCRUM ou Kanban pour les tâches de maintenance plus quotidiennes, de correction de bogues et de correction de bogues.

En dehors de cela, parler de "culture" est, du côté des développeurs, une chose spécifique à DevOps. Oui, nous avons également nos évangélistes, spécialement pour les nouveautés comme le rubis ou le golang, mais pas aussi extrêmes que dans le monde DevOps / Cloud, où il y a de réels changements de paradigme.

et comment vous digérez le grand nombre de fichiers dans vos projets

Ayant moi-même travaillé sur des applications rubis non triviales, ce n'est pas grave. Vous voyez, ces fichiers ne sont pas simplement éparpillés, mais il y a une hiérarchie, des conventions et tout ça. Vous n'avez jamais vraiment besoin d'avoir tous ces fichiers dans votre tête à un moment donné, pour un projet bien conçu. Si vous travaillez dans une zone spécifique, il est généralement assez clair où se trouvent les fichiers pertinents et vous pouvez les zoomer assez facilement. Idem devrait aller pour d' autres environnements de programmation modernes.

Dans les mauvaises applications, c'est différent, mais le développeur ne "digèrera" rien, mais trébuchera dans la frénésie toute la journée jusqu'à ce qu'il quitte. ;)

AnoE
la source