Estamos criando um projeto de nuvem para desenvolvimento - uma plataforma que pode simplificar a vida de desenvolvedores, desenvolvedores, testadores, líderes de equipe e outros especialistas envolvidos no processo de desenvolvimento, tanto quanto possível. Este produto não é para agora e nem para amanhã, e a necessidade dele está apenas sendo formada.
A idéia principal é que você pode implantar o pipeline com ferramentas já pré-configuradas, mas, ao mesmo tempo, com a capacidade de fazer várias configurações, basta implantar o código.
De onde vem essa perversão? Vemos uma tendência clara de que agora a velocidade de implantação de novos projetos afeta o mercado. O comércio depende da rapidez com que os lançamentos são entregues. Com a rapidez com que os bugs serão corrigidos, a rapidez com que novos nichos serão envolvidos. No início de 2018, a empresa global "451 Research" realizou uma pesquisa sobre quais tecnologias serão uma prioridade para o desenvolvimento. Os dez principais incluem tecnologias de criação e gerenciamento de contêineres, bem como arquitetura de aplicativos sem servidor e microsserviços, superando até mesmo um assunto tão hype como blockchain.
E agora temos algumas perguntas para você.
Gráfico da pesquisa:
É necessário?
O uso de contêineres no desenvolvimento de um novo produto tem suas vantagens e desvantagens. A utilização ou não dessa tecnologia deve ser decidida com base nas tarefas definidas. Para várias tarefas, o uso de contêineres não pode ser dispensado e, para algumas, são simplesmente supérfluos. Por exemplo, para sites com pouco tráfego, uma arquitetura simples de dois servidores será suficiente. Porém, se estiver planejado um crescimento significativo no desenvolvimento e um grande aumento de visitantes em pouco tempo, nesse caso, vale a pena considerar a infraestrutura que utiliza contêineres.
O uso de contêineres tem várias vantagens:
- Cada aplicativo é executado isoladamente em seu próprio contêiner, o que minimiza os problemas relacionados à configuração.
- A segurança do aplicativo também é alcançada isolando cada contêiner.
- Devido ao fato de os contêineres usarem o kernel do sistema operacional, agora o sistema operacional convidado não é necessário, devido ao qual uma grande quantidade de recursos é liberada.
- Além disso, devido ao uso do kernel do sistema operacional e porque você não precisa confiar no hipervisor, os contêineres exigem muito menos recursos em comparação com outras pilhas.
- Novamente, devido ao fato de os contêineres não exigirem um sistema operacional convidado, eles são fáceis de migrar de um servidor para outro.
- Devido ao fato de que cada aplicativo é executado em um contêiner isolado, é fácil transferir da máquina local para a nuvem;
- É muito "barato" iniciar e parar o contêiner devido ao uso do kernel do sistema operacional.
Em conexão com tudo isso, acreditamos que a tecnologia de contêiner atualmente seja a pilha mais rápida, mais eficiente em termos de recursos e mais segura. Devido às vantagens dos contêineres, você pode ter o mesmo ambiente na máquina local e na produção, o que facilita o processo de integração contínua e entrega contínua.
Os benefícios dos contêineres são tão convincentes que eles definitivamente serão usados por muito tempo.
O que a nuvem tem a ver com desenvolvimento?
No mundo ideal do desenvolvedor, qualquer código de confirmação deve ser lançado em produção com o clique de um botão, como se por mágica.
Tínhamos assim: existe um Gitlabchik com tarefas e uma fonte. Quando você precisa coletar algo - GitLab Runner. Trabalhamos no Git Flow, todos os recursos em filiais separadas. Quando uma ramificação entra no repositório, testes nesse código são iniciados no GitLab. Se os testes forem aprovados, o desenvolvedor desse encadeamento poderá fazer uma solicitação de mesclagem, na verdade uma solicitação de revisão de código. Após a revisão, o ramo é aceito, mesclado no ramo dev, os testes passam por ele novamente. Ao implantar, o GitLab Runner coleta o contêiner do Docker e o rola para o servidor intermediário, onde pode ser clicado e regozijado. E aqui está a primeira mordaça - examinamos o código com nossas mãos para garantir a conformidade com o funcional e essa é a primeira coisa que corrigimos. Depois disso, injetamos o código no ramo de lançamento. E para ela, estamos lançando uma versão pré-produtiva separada de nossa solução, que nossos clientes empresariais estão assistindo. Depois que a versão é pré-instalada no pré-prod, lançamos em produção e ela é lançada nos nós do produto. Existem notas de versão e relatórios de erros gerados automaticamente. A velocidade de montagem foi superior a 30 minutos, agora é uma ordem de magnitude menor. Selecionamos um conjunto de ferramentas para nós mesmos e agora estamos pensando em como fazer o mesmo SaaS pronto.
Para nós, o processo típico de lançamento é o seguinte:
- Estabelecendo objetivos para a implementação de novos recursos
- Localização de código
- Fazendo alterações de acordo com as tarefas. Escrevendo testes automatizados antes da compilação.
- Verificação de código, manual e autoteste
- Mesclando código em uma ramificação de desenvolvimento
- Construa um ramo de desenvolvimento
- Implantar a infraestrutura de teste
- Implantar versão na infraestrutura de teste
- Executando testes, funcionais, integração etc.
- Em caso de erros, termine-os imediatamente no ramo dev
- Migrando uma ramificação de desenvolvimento para uma ramificação principal
Aqui está um diagrama com detalhes para o nosso processo:
Na verdade, a primeira pergunta - por favor, diga-nos onde você ajuntou que tipo de rake era e quão universal ou não esse esquema é. Se você usa um fluxo de trabalho muito diferente disso, adicione algumas palavras, por que?
Que tipo de produto estamos planejando?
Decidimos não copiar a Amazon a esse respeito, mas conduzir nosso desenvolvimento levando em consideração as especificidades do mercado. Imediatamente, faça uma reserva de que todos os cálculos são nossa opinião subjetiva com base em nossa análise. Estamos abertos a um diálogo construtivo e prontos para alterar o roteiro do produto.
Ao analisar o pipeline existente da Amazon, chegamos à conclusão de que ele possui enormes capacidades, mas a ênfase está em equipes corporativas muito grandes. Pareceu-nos que, para implantar um microsserviço no Docker, é excessivamente longo, mais do que se, por exemplo, fosse implantado no Kubernetes, porque existe um lugar para configurar configurações internas, definir acordos internos etc. e tudo isso precisa ser entendido por um longo tempo.
Por outro lado, há, por exemplo, Heroku, onde você pode implantar com um clique. Porém, devido ao fato de que os projetos, em regra, são bastante ramificados, com microsserviços de terceiros, em algum momento torna-se necessário implementar imagens personalizadas do Docker com serviços DBaaS e tudo isso não se encaixa no Herocku porque é caro. desconfortável.
Queremos encontrar outra opção. A média de ouro. Dependendo do tipo de projeto e tarefas, forneça um conjunto de ferramentas já pré-configuradas que já estão integradas em um único pipeline, deixando a possibilidade de uma alteração profunda nas configurações e a capacidade de substituir as ferramentas.
Então, o que será?
Ecossistema, que inclui um portal e um conjunto de ferramentas e serviços para minimizar a interação dos desenvolvedores com o nível de infraestrutura. Você define parâmetros ambientais que não estão vinculados ao ambiente físico:
- Ambiente de desenvolvimento (sistema de gerenciamento de configuração, sistema de definição de tarefas, repositório para armazenamento de código e artefatos, rastreador de tarefas)
- CI - Integração Contínua (montagem, infraestrutura e orquestração)
- QA - Quality Assurance (teste, monitoramento e registro)
- Teste - Ambiente de Integração / Loop de Pré-lançamento
- Produção - Circuito Produtivo
Escolhendo ferramentas, focamos nas melhores práticas do mercado.
Construiremos a infraestrutura com o Stage e Prod usando o Docker e o Kubernetes com o recurso paralelo de varredura.
Isso acontecerá iterativamente - no primeiro estágio, está planejado um serviço que permitirá que você retire o arquivo do Docker do projeto, colete o contêiner necessário e os expanda ao Kubernetes.
Também planejamos prestar atenção especial ao serviço para monitorar o processo de desenvolvimento e a entrega contínua. O que queremos dizer com este serviço? Esta é uma oportunidade para criar um modelo hierárquico de KPI com indicadores como% de cobertura por testes de unidade, tempo médio para eliminar um incidente ou defeito, tempo médio de confirmação até a entrega, etc.
A coleta de dados de origem de diferentes sistemas - sistemas de gerenciamento de teste, gerenciamento de tarefas, componentes de CI / CD, ferramentas de monitoramento de infra-estrutura etc.
E o mais importante é mostrar de forma adequada, disponível para análise rápida - painéis com a possibilidade de pesquisa detalhada, análise comparativa de indicadores.
O que queremos fazer
Na verdade, eu realmente gostaria de ouvir você sobre tudo isso e nossos planos para etapas. Agora eles são:
- Infraestrutura e orquestração - Docker & Kubernetes
- Configuração de tarefas, armazenamento de código e artefato, rastreador de tarefas - Gitlab, Redmine, S3
- Produção e Desenvolvimento - Chef / Ansible
- Assembléia - Jenkins
- Teste - Selênio, LoadRunner
- Monitoramento e registro - Prometheus & ELK
- A propósito, como você vê se dentro da plataforma haverá uma escolha - se você quisesse, escolheu Jenkins, não - GitLab Runner?
- Ou não importa o que está dentro, o principal é que tudo seja construído, testado e implantado corretamente?
Como alguém pode ajudar?
O produto será desenvolvido para desenvolvedores domésticos. Se você agora nos disser como fazer isso, é provável que ele seja incluído no lançamento.
Por favor, diga-me quais pilhas você está usando no momento. Você pode - nos comentários ou por e-mail para team@ts-cloud.ru.
UPD: por conveniência, fizemos um pequeno questionário no formulário do Google -
aqui .
Além disso, manteremos você atualizado com o desenvolvimento - e em algum momento concederemos aos participantes assistentes o acesso à versão beta (na verdade, acesso gratuito a bons recursos de computação da nuvem em troca de feedback).