O DevOps está restrito a empresas com produtos SaaS?

As práticas que descrevem o DevOps, como entrega contínua, automação etc. são relevantes para produtos que fornecem serviço contínuo, como produtos SaaS.

Por exemplo, uma empresa de desenvolvimento de software que realiza projetos para outros clientes nunca poderá ser mantida após o término do projeto. E projetos de clientes não são compartilhados com outros clientes, porque são irrelevantes.

O DevOps se aplica a empresas que desenvolvem vários projetos pontuais? Quais práticas de DevOps se aplicam nesse caso, se houver?

Absolutamente não!

O DevOps tem tudo a ver com quebrar os silos tradicionais (departamentos) para ser mais eficiente.

Melhor comunicação entre equipes, maior visibilidade e processos confiáveis ​​e automatizados são formas de obter um produto melhor.

Eu trabalhava para uma grande empresa de mídia, onde fornecíamos suporte a uma ferramenta interna e desenvolvia sites voltados ao público.

Os benefícios do DevOps no nosso caso foram os seguintes:

• Através da construção contínua, informamos a equipe de desenvolvimento mais cedo ou mais tarde se houver integração ou criar problemas com seu código. Eles podem corrigir problemas enquanto sua mente ainda está no código que acabaram de confirmar.
• Por meio de testes e entrega contínuos (no controle de qualidade), permitimos à equipe de controle de qualidade encontrar problemas mais cedo e relatá-los mais cedo. Isso reduziu o tempo necessário para encontrar e corrigir erros, além de reduzir a complexidade dessas investigações.
• Com as ferramentas de coleta e agregação de logs, demos aos desenvolvedores acesso a algo que eles normalmente não olhavam (eles gostavam muito dos depuradores :) - entender como os logs são vistos e usados ​​por outras equipes melhorou a qualidade geral dos logs
• Muitas vezes compartilhamos informações e criamos documentação para compartilhar conhecimento entre equipes, tentando derrubar barreiras. Ao entender as necessidades do Ops, criamos alguns guias para o que sempre deve ser lembrado ao inicializar um aplicativo (onde / como gerenciar propriedades, etc.). Ao entender a realidade do desenvolvedor (codifique mais recursos, mais rápido, gogogogo!), Conseguimos que as operações criassem servidores e clusters que eram mais adequados às necessidades do desenvolvedor.
• A qualidade geral das implantações também foi bastante aprimorada. As implantações foram gerenciadas por nossa equipe, por isso tivemos uma visibilidade perfeita nos Ops e Dev. Isso eliminou muitos problemas relacionados à "transferência de código", na qual o desenvolvedor entregava um pacote e um documento de uma página para as operações dizendo "Instalar isto!".

No geral, eu diria que, independentemente de você estar atualizando seu ambiente de produção uma vez por dia ou uma vez por mês e independentemente de quantos clientes você tem ou seu modelo de negócios, cada empresa pode usar melhor comunicação, melhores ferramentas, melhor visibilidade, feedback mais rápido, etc.

Minha equipe e eu somos responsáveis ​​pelo desenvolvimento de "one-offs", produtos que, uma vez terminados, são entregues ao cliente para manutenção ou, em alguns casos, gerenciados por nós mediante taxa.

Ainda precisamos manter um pipeline de desenvolvimento sólido para lidar com o feedback constante de nossos clientes, a fim de garantir que enviámos a eles algo confiável e comprovado em sua execução.

Embora o cliente não se importe com o DevOps (na maioria dos casos), ainda é útil para nós. Com o DevOps, podemos desenvolver rapidamente novas compilações, para que os clientes possam ver o feedback em minutos, não em horas, e também podemos detectar quaisquer erros / bugs em nossos testes via Jenkins / Travis.

Para garantir que nossas estratégias de implantação sejam as mesmas nos projetos, nos concentramos em contêineres de nossos aplicativos. Usando o Docker, somos capazes de entregar facilmente o aplicativo aos nossos clientes.

O custo economizado pelo DevOps é difícil de determinar. Temos custos extras na forma de software que escolhemos usar para o pipeline (Travis, Jenkins, Puppet, o que você tem), mas também economizamos tempo e dinheiro corrigindo bugs / fornecendo feedback aos clientes rapidamente. Nosso rápido tempo de resposta mantém nossos clientes satisfeitos, por sua vez, mantendo nossas carteiras felizes.

Trabalhei para empresas que produzem software como produtos shrink-wrap, implantações totalmente instaladas e suportadas e como código incorporado em dispositivos. Em todas essas empresas, o DevOps fornece suporte essencial para o desenvolvimento:

• Compilações de software automatizadas e reproduzíveis, com configurações conhecidas e controladas de compiladores, bibliotecas e outras ferramentas de compilação.
• Testes de sistema automatizados e repetíveis para testes de regressão e para novos testes de funcionalidade.
• Outras ações automatizadas e regulares (por exemplo, capturas de tela de amostra atualizadas continuamente disponíveis em todos os idiomas suportados, para verificação de tradutores e incorporação de autores técnicos nos manuais do usuário).

Em todos os casos, são coisas que os desenvolvedores individuais poderiam fazer como pontuais, mas que não seriam um bom uso do tempo do desenvolvedor, nem terão a mesma garantia de controle de configuração que as compilações automatizadas.

As atividades de desenvolvimento e implementação de software anteriormente não exigiam profunda integração entre os departamentos. Hoje, porém, é necessário cooperar estreitamente com todos os departamentos (desenvolvimento, operações de TI, garantia de qualidade etc.).

Para os desenvolvedores, a mudança é o que eles recebem. Os negócios sempre precisam de mudanças para combinar com o mundo moderno. Esse entendimento leva os desenvolvedores a produzir o número máximo possível de alterações. Os profissionais de TI têm um entendimento diferente, no qual a mudança é prejudicial. Cada um deles acha que funciona corretamente, beneficiando os negócios. De fato, se os considerarmos separadamente, ambos estão certos.

Todos os funcionários devem entender que fazem parte de um único processo. O DevOps cultiva o pensamento, o que torna possível perceber que as decisões e ações pessoais de todos devem ser direcionadas para a realização de um único objetivo. E o sucesso deve ser medido em relação a todo o ciclo de desenvolvimento até a entrega, e não do sucesso de papéis individuais. Como resultado da estreita cooperação entre desenvolvedores e especialistas em manutenção, é formada uma nova geração de engenheiros, que obtêm as melhores realizações de ambas as disciplinas e as combinam para o benefício do usuário. Isso se manifesta na aparência de equipes multifuncionais com experiência em desenvolvimento, gerenciamento de configuração, gerenciamento de banco de dados, teste e gerenciamento de infraestrutura.

Portanto, a metodologia é útil não apenas no SaaS.

De modo nenhum. Embora já existam ótimos exemplos neste tópico, gostaria de compartilhar uma anedota minha. Em 2001, herdei um projeto de software com um release que envolvia a criação de um CD. A documentação para o processo de liberação incluiu 40 (!) Etapas documentadas por um engenheiro anterior, que incluiu algumas instruções manuscritas ridículas como "abra este arquivo de configuração e altere o nome do arquivo .jar na linha 41 para incluir o número da versão de o novo lançamento ".

Automatizamos agressivamente todas as etapas desse processo de construção, substituindo instruções escritas à mão por coisas como 'patch' com script bash. Tivemos até que abrir tickets com nosso fornecedor de ferramentas de instalação de terceiros para tornar seus arquivos de projeto acessíveis.

Uma vez que esse processo foi automatizado, compramos um 'CD Jukebox'. Todas as noites após a aprovação dos testes, a máquina de criação criava automaticamente um novo CD de instalação. Nossos testadores podem entrar na manhã seguinte, pegar um disco e garantir que tudo esteja instalável.

Certamente, temos ciclos de feedback mais rigorosos quando podemos implantar software como serviço, mas os principais princípios de automação, feedback, tempo de ciclo, pequenas versões etc. se aplicam.