O DevOps está restrito a empresas com produtos SaaS?

26

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?

Evgeny
fonte

Respostas:

32

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.

Alexandre
fonte
11
De fato, o DevOps pode ser aplicado a praticamente qualquer organização de desenvolvimento de sw, mesmo para grandes produtos incorporados com apenas um punhado de lançamentos públicos por ano - usando entrega contínua dentro de seu pipeline de desenvolvimento, eles ainda podem obter alguns benefícios do DevOps: melhor qualidade, redução de custos, previsibilidade de lançamento, etc.
Dan Cornilescu
A resposta lembra um SaaS, não explica muito bem como um produto ou serviço que não seja SaaS pode se beneficiar dessas práticas.
Evgeny
Os produtos em que eu estava trabalhando não eram SaaS (muito pelo contrário). Mas a lógica permanece a mesma, não importa muito se você é SaaS ou não, o DevOps tenta melhorar o produto de maneiras não tradicionais. Eu não sabia nada sobre nosso modelo ou oferta de preços, não faria muita diferença.
219 Alexandre Alexandre
13

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.

Tartaruga
fonte
Você pode fornecer algumas razões e benefícios de por que isso é importante? Os clientes realmente se preocupam com o seu pipeline ou apenas o projeto finalizado na data prometida e o preço que precisam pagar? Você poderia cortar custos se não fizesse todas essas coisas "devops-y"? Você poderia obter mais horas em um projeto se não fizesse essas coisas e conseguir mais dinheiro para os projetos (já que é mais longo)?
Evgeny
11
O @Evgeny DevOps ajuda a finalizar o projeto dentro do prazo e do orçamento, pelos motivos explicados na minha resposta. Ao cortar no DevOps, você também cortaria os benefícios que expliquei. Construir e testar geralmente ajudam a manter o orçamento e o prazo. Encontrar um bug mais tarde custa mais dinheiro e leva mais tempo para consertar, foi provado várias vezes. O cliente não se importa com o pipeline, mas quanto mais você esperar pelo feedback, mais dispendiosa e demorada será a reescrita.
214 Alexandre Alexandre
Não é apenas o Agile Software Dev?
Evgeny
@ Evgeny Atualizei minha resposta para esclarecer. Nós uso Agile, mas isso não significa que não podemos ter uma mentalidade DevOps ..
Turtle
11
@ Evgeny, você provavelmente poderia economizar alguns não mantendo seus testes de unidade e testes de aceitação, mas isso cria Dívida Técnica, que é um anti-padrão do DevOps. Você pode se safar por algumas semanas ou meses, mas em breve acabará (provavelmente) com uma bagunça difícil de manter, impossível de testar.
21420 Steve
3

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.

Toby Speight
fonte
Automação não é devops. Mesmos comentários como resposta de David Bock abaixo, finalmente, (desculpe, meu comentário foi perdida no momento I downvoted, só notei isso)
Tensibai
3

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.

Quarind
fonte
0

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.

David Bock
fonte
Esta é a automação relacionados, mas não relacionada a uma organização DevOps de qualquer forma, não vejo nenhuma referência em qualquer lugar plury equipe disciplina, apenas ops automatizando as coisas que eles herdam
Tensibai
Isso foi em 2001 ... muito antes do DevOps ser uma coisa. Isso não era apenas automação, acredito que isso simplificou o gerenciamento do projeto exatamente da mesma maneira que acabou sendo rotulada de 'Cultura' do DevOps. Como tal, é um exemplo da atitude do DevOps fora de uma organização SaaS.
David Bock
O DevOps não é sobre automação, nem gerenciamento de projetos. Trata-se de quebrar a organização baseada em silo na raiz. Sinto muito, mas não sinto que esta resposta esteja realmente relacionada à pergunta (isso não significa que seja desinteressante, mas não no lugar certo da IMO, e não vejo onde ela possa estar na verdade, pode vir mais tarde)
Tensibai 03/03
Tentarei esclarecer mais uma vez - cortando o CD com tanta consistência e rapidez, poderíamos obter feedback do controle de qualidade muito mais rapidamente do que antes. Isso reduziu um silo. Não o eliminou, pois levou mais um ano ou dois antes de desativarmos os feudos em torno dos orçamentos centralizados para as atividades, mas certamente foi uma etapa crítica no processo de acontecer. Também sabíamos muito mais cedo quando o processo de lançamento foi interrompido. Eu credito muitas pequenas coisas como essa como meu caminho pessoal para o DevOps.
David Bock
Este último comentário traz mais sentido a esta resposta nesta pergunta. Você deve editar para incluí-la. Ainda acho que isso não se encaixa nesse formato, mas parece que minha posição está errada quando observo a evolução geral dessa versão beta privada. ... isso é contigo. Eu não posso retirar o meu downvote sem uma edição para obter informações
Tensibai