DevOps significa que os desenvolvedores agora assumem a responsabilidade pela infraestrutura e pelo lançamento - mas quais são os drivers por trás dessa mudança?

18

Vou colocar minhas cartas em cima da mesa: sou desenvolvedor e já trabalhei em "DevOps" e em não culturas. Ter que se preocupar com infraestrutura, lançamentos, controle de qualidade e a cerimônia associada é uma grande distração para escrever um bom código.

Mas a indústria está caminhando nessa direção, então quais são as razões para isso? Quais problemas o "velho" modelo de especialização de função gerou?

process devops

— Ben
fonte

4

Você está dizendo que a qualidade do seu código está diminuindo porque você faz outras coisas ou a quantidade do código está diminuindo.

— Caleth

1

Leve seus cartões fora da mesa, por favor. Isso parece uma reclamação como está.

— svidgen

7

@svidgen Se essa pergunta fosse puramente divertida, seria diferente, mas o OP tem o direito de expressar sua opinião e fazer uma pergunta perfeitamente válida.

— Robbie Dee

1

@robbie com certeza. você notará que eu respondi de qualquer maneira ... mas, a parte "opinião" desta pergunta consome mais da metade do corpo, imprensada entre a mesma pergunta básica reiterada e distrai a pureza potencial da pergunta básica neste caso. Mas sim. Ainda vale a pena responder ..

— svidgen

19

O principal motivo é a nuvem.

Antes, seu código era enviado em disquete, e depois em CD, e depois em um servidor, e em dois servidores (para resiliência) ... E toda essa implantação podia ser feita manualmente por um humano, então os humanos foram treinados para fazê-lo.

Hoje, seu código costuma ir para dezenas ou centenas de servidores. O provisionamento, a configuração e a implantação nesses servidores não podem ser feitos realisticamente manualmente por um ser humano. Você precisa que os administradores do seu sistema conheçam scripts suficientes para automatizar esse processo, pois agora você está usando o Chef ou seus parentes. Mas, francamente, não havia administradores de sistemas suficientes que pudessem fazer isso. Então os desenvolvedores foram contratados para pegar a folga.

E sim, adicionar mais habilidades aos crescentes requisitos dos desenvolvedores reduzirá naturalmente sua competência em outros lugares. A idéia é que, permitindo que o desenvolvedor perceba o processo de criação / liberação, eles podem antecipar melhor os problemas ou ter autonomia para aprimorá-los. A ideia é que a qualidade de tudo aumente desde que o lançamento supere as perdas de codificação.

Sou cético de que o trade-off valha a pena com a frequência que as pessoas fazem.

— Telastyn
fonte

2

Você me perdeu em " A principal razão é a bunda ".

— tedder42

15

Existem várias razões para várias organizações mudarem para o DevOps.
Vou tentar listar os que aparecem com frequência.

Reduzir o tempo para mudar o ciclo
Muitas vezes há muito tempo entre fazer uma solicitação de mudança e realmente ser implantada e usada na organização. Primeiro, ele é planejado em um dos ciclos de desenvolvimento pelos desenvolvedores e, após a entrega, é planejado em um dos ciclos de liberação das operações. Ambos os ciclos incluem teste e, em caso de problemas encontrados, os dois ciclos são redefinidos. Ao integrar os departamentos de desenvolvimento e operações, podemos otimizar os dois processos.

Problemas de software x hardware
Lembre-se do desenho animado Bugs Bunny, onde Bugs e Daffy estão discutindo se é época de pato ou coelho? Agora imagine que fizemos isso com desenvolvedores e operações, onde os desenvolvedores argumentam que é um problema de hardware e as operações argumentam que é um problema de software. Para o usuário final, essa é uma distinção sem diferença. Eles só querem que seja consertado.
Ao reunir desenvolvedores e operações, eles terão que corrigir os problemas. E pode acontecer que tenha sido um problema de software e hardware.

Nós vs. eles
Em muitas empresas, a distância entre testadores e desenvolvedores estava aumentando porque eram departamentos separados e o ciclo de desenvolvimento estava ficando cada vez mais formalizado e padronizado.
Com a chegada do Agile, desenvolvedores e testadores têm trabalhado mais juntos e começamos a ver o ponto de vista um do outro no ciclo de desenvolvimento e talvez até respeitá-lo.
Algo semelhante precisa acontecer entre desenvolvedores e operações, porque, à medida que os campos amadurecem e os processos formalizam e padronizam, a distância entre esses departamentos aumenta. Portanto, um dos problemas do modelo tradicional é que parece "nós" versus "eles" para desenvolvedores e operações. Ambos não compreendem completamente a dificuldade das responsabilidades do outro.

Expectativas / vantagens:
Com o DevOps, as duas especialidades aprenderão algumas das habilidades tradicionalmente desempenhadas pela outra. Ninguém espera que um administrador de sistemas se torne um engenheiro de software ou um desenvolvedor se torne um engenheiro de rede, mas espera-se que ambos assumam algumas das responsabilidades do outro. Isso significa que quando você realmente precisa de algumas mãos extras, elas estão lá.

E existem algumas vantagens definitivas para os desenvolvedores: agora você tem mais controle sobre seus ambientes de teste, acha mais fácil implantar software para os usuários e tem mais pessoas em sua organização para compartilhar seu amor pelo ofício.

— Miguel van de Laar
fonte

4

+1 - Porque se trata do usuário final e não apenas do código.

— JeffO 7/06

3

Escrever código de qualidade simplesmente não é suficiente. Você é parte do problema ou parte da solução.

Para muitos programadores, você está escrevendo um software que está sendo pago por algum usuário final. Escrever código de qualidade é uma coisa boa, mas também é algo que os clientes / gerentes assumem que você deve sempre fazer e fazer rápido. É como dizer que um carpinteiro corta tábuas com precisão, mas você está realmente construindo algo pelo qual alguém quer pagar?

O DevOps oferece aos desenvolvedores mais controle e, com sorte, força o código a estar alinhado com o resultado final. Quem é o mais adequado para automatizar o processo de operações? A satisfação do usuário final é o principal ponto de medição. Você não apenas deve escrever um código de qualidade, mas também para satisfazer o cliente. Desculpe, mas ninguém está voltando a usar linhas de código. Eles não se importam se você construiu sua própria estrutura ORM do zero, assim como o comprador comum de imóveis não se importa se você derrubou a árvore e fez suas próprias pranchas. Alguém quer refazer todos os seus arquivos de configuração porque sua "atualização" os coloca de volta ao padrão?

Deseja mostrar suas costeletas de desenvolvedor? Crie algo que as pessoas desejam comprar e que inclua toda a experiência do usuário. É ótimo escrever um código de qualidade, mas, infelizmente, você pode não receber um bônus se ele não for liberado para a satisfação do cliente pagador. Sinta-se à vontade para culpar o controle de qualidade, mas sua empresa ainda não tem dinheiro suficiente para pagar mais.

— JeffO
fonte

2

Tenho certeza que você sabe o quão difícil é contratar bons desenvolvedores de software. E agora precisamos que eles sejam bons analistas de negócios, interessados na cerimônia de controle de qualidade e se preocupem com os processos de lançamento. O número de pessoas que conhecer o novo bar será muito pequeno.

— Ben

2

@ Ben: Não há "e agora"; essas são coisas que bons desenvolvedores estavam fazendo décadas antes de alguém pensar que o DevOps era uma coisa nova e cunhou o termo. Seu trabalho como desenvolvedor é resolver problemas que se estendem da necessidade de alguém por uma solução, para garantir que as pessoas que precisam manipular seu código depois que você o tenha escrito não tenham dificuldades. Economize um pouco e ninguém vai se importar com a beleza de suas estacas quadradas, se precisar de um trenó de dez libras para levá-las a buracos redondos.

— Blrfl

Parece um argumento contra a especialização. Que uma pessoa deve ser um valete de todos os negócios, mestre de ninguém. Isso não é sugerido em qualquer outra indústria, você não tem electrition-pedreiro-encanador-telhados tentando entender cada pouquinho sobre a construção de uma casa

— Richard Tingle

2

@RichardTingle: Ninguém está dizendo que você precisa entender tudo, mas precisa entender o que seu produto tocará quando usado. Um encanador precisa saber o suficiente sobre o que os eletricistas fazem - ou pelo menos trabalhar com um - para saber que não é seguro passar um cano de água fria por um disjuntor, mesmo que haja nocautes disponíveis para isso.

— Blrfl

Nem se importa em tentar responder à pergunta. -1

— RubberDuck

2

É algo que andou de mãos dadas com o Agile & Scrum. Não há mais funções de trabalho claramente definidas - todo mundo é um "desenvolvedor".

E não são apenas ops. Os desenvolvedores geralmente precisam assumir a análise de negócios, testes, administração de banco de dados e criar funções de gerente - a lista continua.

No centro do problema estava o que você poderia chamar de rotatividade . À medida que o número de diferentes papéis envolvidos em um projeto aumentava, mais reuniões, mal-entendidos e conflitos de recursos aconteciam. Colocar o software na frente dos usuários rapidamente é o fim do jogo e qualquer coisa que possa atrapalhar o que aconteceu foi um pouco diferente.

Isso não é totalmente ruim. Seu desenvolvedor média se expande suas habilidades embora o congestionamento está ficando muito fina agora. Ele também elimina os argumentos entre codificadores e administradores de servidor sobre onde estão os problemas quando as implantações seguem o caminho da pera. Os desenvolvedores geralmente desejam oferecer soluções com tecnologia de ponta e os administradores de servidor geralmente não têm idéia do que isso significa para um POV de administrador até que eles sejam apresentados ao conjunto de instalação.

As empresas mais brilhantes e com visão de futuro estão finalmente começando a perceber que as pessoas em forma de T são uma coisa boa. No entanto, existe uma diferença entre pensar que é uma coisa boa e esperar que isso aconteça magicamente onde uma cultura tradicional havia sido adotada anteriormente.

— Robbie Dee
fonte

-1 "não são mais funções claramente definidas - todo mundo é desenvolvedor." Isso não é totalmente verdadeiro. Supõe-se que uma equipe de scrum seja composta por um conjunto diversificado de pessoas, que inclui desenvolvedores, artistas gráficos, pessoal de TI etc. As funções não desaparecem, mas a ideia é que agora elas estão em uma única equipe, não departamentos separados.

— Andy

1

@ Andy: sugiro que você leia o guia scrum novamente: Scrum não reconhece títulos para os membros da equipe de desenvolvimento que não sejam Developer, independentemente do trabalho que está sendo realizado pela pessoa; não há exceções a esta regra . As pessoas, é claro, se especializam, mas por sua própria natureza, é suposto ser uma entidade auto-organizada.

— Robbie Dee

Chamar alguém com especialidade em criar gráficos no Photoshop, ou alguém com papel em traduzir, um desenvolvedor é enganoso, pois desenvolvedor de projetos de software é universalmente entendido como desenvolvedor de software. O guia scrum está simplesmente errado com essa afirmação.

— Andy

0

Tenho certeza de que existem algumas boas razões para os desenvolvedores também gerenciarem operações e controle de qualidade (às vezes). Aqui estão três deles:

Interesse
Alguns desenvolvedores realmente querem trabalhar todos os aspectos do produto. Se eles são bons nisso, e se estão preenchendo um vazio na equipe ou fornecendo um bom suporte aos membros da equipe existentes em outras funções, pode não haver motivo para pará-los.
Custo As
grandes empresas podem pagar funcionários especializados. As pequenas empresas às vezes não conseguem. Alguns desses lugares podem contratar 1 ou talvez 2 ou 3 desenvolvedores que precisam ser capazes de simplesmente colocar as coisas do lado de fora da porta.
Tamanho do projeto
Nem todo projeto é de muitas pessoas. Se você estiver criando um aplicativo "pequeno", pode ser um exagero ter mais de uma pessoa trabalhando nele até o fim. Além disso, pequenos projetos com muitas pessoas trabalhando em funções específicas são assustadores . Ninguém tem bastante trabalho a fazer - mesmo se você pode ter recursos para mantê-los todos ao redor para mexer os dedos polegares por 6 meses, os bons não vai ficar. Se eles não ficarem entediados, ficarão assustados, ou você perceberá que está pagando um pouco por nada. De qualquer forma, seus bons funcionários estarão saindo e dizendo a todos para ficarem longe de você.

... E outras razões, tenho certeza.

— svidgen
fonte

0

"Ter que se preocupar com infraestrutura, lançamentos, controle de qualidade e a cerimônia associada é uma grande distração para escrever um bom código"

Na essência, acho que o DevOps diz que se preocupar com infraestrutura e lançamentos e o controle de qualidade está escrevendo um bom código.

Em funções anteriores que operam em culturas que não são DevOps, tive vários problemas que, sem dúvida, uma cultura DevOps poderia ter evitado; problemas de desempenho relacionados ao código desenvolvido em plataformas não representativas, problemas de codificação de caracteres em que os desenvolvedores desconheciam as codificações de caracteres usadas por um cliente, instruções de implantação que foram codificadas manualmente e insuficientes para a equipe de operações sem algum palpite -trabalhos.

Agora você pode argumentar que o aumento da especialização nos lados de Dev e Ops nos permite superar alguns deles, mas ainda assim muitos podem ser resolvidos através de algum compartilhamento de conhecimento e trabalho entre nossas equipes.

— freake mate
fonte

0

DevOps não precisa significar "Dev now do também Ops". O termo originalmente significava "as pessoas de Dev e Ops trabalham juntas em uma equipe". Ele faz significa que o Ops pessoas precisam se tornar mais parecido com Devs, porque automatizar coisas requer algum tipo de programação, e o velho modo manual não cortá-la (ver as outras respostas para elaboração mais detalhada sobre este ponto).

Da Wikipedia :

O DevOps (um composto reduzido de desenvolvimento e operações) é uma cultura, movimento ou prática que enfatiza a colaboração e a comunicação de desenvolvedores de software e outros profissionais de tecnologia da informação (TI), automatizando o processo de entrega de software e alterações na infraestrutura

Portanto, na minha opinião, na verdade, se você, como desenvolvedor, tem as mesmas responsabilidades antigas e agora também as responsabilidades de operações, isso parece um erro de cálculo da parte de gerenciamento. Ao automatizar as coisas, é bem possível que você precise de menos Ops e, portanto, haja realmente economia de custos. Mas o DevOps certamente não significa "Vamos nos livrar de todas as pessoas da Ops e deixar os Devs para o trabalho adicional".

Como tantas vezes com o Buzzwords, acontece uma difusão semântica , e de repente as pessoas pensam "Vamos fazer os Devs fazerem Ops também, e acho que podemos economizar dinheiro ..."

— jhyot
fonte