Crash course in Dev for Ops?

10

Eu estudei no CompSci, onde aprendemos principalmente sobre Java, mas o que aprendi é que minha paixão são sistemas, por isso sempre trabalhei no lado das operações. Sou útil em scripts, portanto, não estou procurando um site para me ensinar Ruby, mas algo para explicar mais detalhadamente o que os desenvolvedores fazem o dia todo. Quero entender melhor a cultura e como você digere o grande número de arquivos em seus projetos - os intangíveis.

Se soubesse hoje que estava sendo transferido para uma equipe de desenvolvimento na segunda-feira, o que gostaria de ler neste fim de semana?

— Stephen C
fonte

3

Eu começaria a ler meu "contrato" ... mesmo que fosse apenas se você precisasse renegociar seu salário ... Além disso, apenas um fim de semana não é suficiente para ler algo relevante, especialmente porque você não parece saber com que tipo de "infraestrutura" você estará trabalhando ... imagine que seja um mainframe executando todos os tipos de instâncias do zLinux ... com o "z" sendo um atalho para tempo de inatividade zero (não negociável). .. para manter os aviões no ar ...

— Pierre.Vriens

@ Pierre.Vriens, comentário hilário. Tenha certeza de que isso não está realmente acontecendo ou eu estaria ocupado com minha conta do LinkedIn no momento, mas não acho que esse tipo de ação seria extraordinária atualmente. Algumas organizações podem realmente se beneficiar trocando alguns membros da equipe entre equipes de desenvolvimento e operações, e tenho certeza de que algumas organizações fazem exatamente isso durante os drives para "implementar DevOps".

— Stephen C

8

Como você marcou essa pergunta como "cultura", presumo que você não esteja interessado em um aplicativo específico, mas nas questões mais amplas de fluxo de trabalho e gerenciamento.

Eu provavelmente começaria com "O Manual do DevOps"; é uma boa visão geral de diferentes coisas a considerar, sem mergulhar muito fundo.

"Entrega contínua", de Jez Humble, também é frequentemente mencionado; Ainda não li muito, mas abrange os conceitos de controle de origem e automação de compilações.

Se você está começando a entrar em aplicativos em escala (isso pode ser uma suposição muito grande), outro bom livro é "A Prática da Administração de Sistemas em Nuvem", de Limoncelli et al.

— Stuart Ainsworth
fonte

11

Li cerca de 60% do livro de Limoncelli antes de perdê-lo. Definitivamente me ensinou muito. Eu também acabei de começar "The Phoenix Project", de Gene Kim et al., Que é uma leitura surpreendentemente atraente, enquanto também ensina muito.

— Stephen C

Eu também gostei do livro do Google SRE; na verdade, é mais adequado para mim na minha organização do que algumas das coisas do DevOps, mas o livro em si é desconexo. Você deve lê-lo fora de ordem, escolhendo os capítulos que lhe interessam e examinando o resto.

— Stuart Ainsworth

7

Não se trata de DevOps, mas de um desenvolvimento direto de software, presumo.

Eu quero entender melhor a cultura

Bem, o importante no desenvolvimento direto (sem o ângulo "DevOps") é certamente "ágil", isto é, na maior parte do tempo, o SCRUM. Você pode fazer pior do que sentar e ler o Agile Manifesto ou uma cartilha no SCRUM ou no Kanban para os trabalhos de manutenção mais corretos do dia-a-dia.

Além disso, falar em "cultura" é, vindo do lado do desenvolvedor, principalmente uma coisa específica do DevOps. Sim, também temos nossos evangelistas, especificamente para coisas mais novas, como ruby ou golang, mas não tão extremas quanto no mundo do DevOps / Cloud, onde há mudanças de paradigma reais acontecendo.

e como você digere o grande número de arquivos em seus projetos

Tendo trabalhado em aplicações rubis não triviais, isso não é nada demais. Veja, esses arquivos não estão apenas espalhados por toda parte, mas há uma hierarquia, convenções e tudo mais. Você nunca precisa ter todos esses arquivos em sua cabeça em um único momento, para um projeto bem projetado. Se você trabalha em uma área específica, geralmente fica bem claro onde estão os arquivos relevantes e é possível fazer zoom neles com bastante facilidade. O mesmo deve acontecer com outros ambientes de programação modernos.

Em aplicações ruins, isso é diferente, mas o desenvolvedor não "digerirá" nada, apenas tropeçará em frenesi o dia inteiro até que saia. ;)

— AnoE
fonte