cds
0.54.1
CDS é uma plataforma de automação de entrega contínua e DevOps de grau corporativo escrito em Go (Lang).
Este projeto está em desenvolvimento ativo
Documentação
O CDS fornece uma interface do usuário intuitiva que permite criar fluxos de trabalho complexos, executá -los e cavar os logs quando necessário.
Crie e execute o fluxo de trabalho com a interface do usuário do CDS.
O CDSCTL é a linha de comando CDS - você pode script tudo com ela, o CDSCTL também fornece alguns comandos legais, como cdsctl shell para navegar seus projetos e fluxos de trabalho sem a necessidade de abrir um navegador.
Veja todos os comandos CDSCTL
Crie fluxo de trabalho como código com a linha de comando CDS.
Docker-Compose é seu amigo, veja os tutoriais prontos para executar
A maioria das ferramentas de CI/CD joga com trabalhos dentro de um pipeline. O CDS apresenta um novo conceito chamado CDS Workflows . Um fluxo de trabalho do CDS permite encadear dutos com gatilhos. Um pipeline é estruturado em estágios seqüenciais contendo um ou vários trabalhos simultâneos.
Sim! O CDS é usado na produção desde 2015 @ovh e lança mais de 7 milhões de trabalhadores do CDS por ano. Você pode instalar o lançamento oficial disponível em https://github.com/ovh/cds/releases
O CDS fornece tudo o que é necessário para monitorar e medir a atividade de produção (toras, métricas, monitoramento)
Todos os dados são armazenados no banco de dados - nada no sistema de arquivos. Basta fazer backup do seu banco de dados regularmente e você estará seguro.
A equipe principal está disponível no Github
Capacidade de executar vários trabalhos simultaneamente, mantendo um isolamento entre eles. Veja o DOC sobre etapas e empregos dentro de um pipeline. Um pipeline é iniciado com um contexto: 0 ou 1 Aplicação, 0 ou 1 ambiente.
Um fluxo de trabalho possibilita encadear os pipelines. Este é um recurso essencial dos CDs. Você pode criar fluxos de trabalho usando um ou mais pipelines, pipelines que podem ser vinculados com junções ou garfos.
Você pode imaginar ter apenas um construtor de fluxo de trabalho e implantar toda a sua pilha de microsserviços. O mesmo pipeline pode ser usado várias vezes em um fluxo de trabalho, você pode associar um aplicativo ou um ambiente. Você terá apenas um pipeline de implantação e um pipeline de construção para manter, mesmo se você tiver centenas de aplicativos.
Um modelo de fluxo de trabalho permite compartilhar e reutilizar fluxos de trabalho em várias equipes. Qualquer usuário pode criar um modelo de fluxo de trabalho, mantê -lo como código ou da interface do usuário e atualizar em massa um conjunto de fluxos de trabalho com uma única ação.
Como empresa, você pode oferecer um catálogo predefinido de fluxos de trabalho, permitindo que você padronize práticas de teste e implantação em todas as suas equipes.
Isso também reduz os esforços de manutenção, pois os modelos permitem um gerenciamento centralizado escalável.
Você pode configurar tudo com a interface do usuário da web. Mesmo se você tiver casos de uso complexos, geralmente é mais fácil criar seus fluxos de trabalho graficamente.
O pipeline como código é um conceito bem conhecido de ferramentas de CI / CD. O CDS vai um passo adiante e oferece fluxo de trabalho como código. Isso é feito por pushing git usando arquivos de configuração da YAML do seu fluxo de trabalho ( + pipeline, + aplicativos, + ambiente). Isso é particularmente útil, pois você pode testar seu novo fluxo de trabalho em uma filial de desenvolvimento, antes de mesclar as alterações na filial principal.
Você pode modificar seu fluxo de trabalho com a interface do usuário, também pode modificar a configuração editando o arquivo YAML diretamente na interface do usuário, se desejar. Esta é uma excelente maneira de aprender a usar o recurso de fluxo de trabalho como código.
Capacidade de iniciar as compilações com base em um padrão de ramificação. Isso permite, por exemplo, implantar ramificações dev/* para "encenar" e implantar a filial mestre em "Prod".
Observe que o comportamento padrão do CDS é iniciar todo o fluxo de trabalho em cada confirmação do Git. Esse comportamento pode ser alterado usando "condições de execução".
Integração bidirecional com os produtos mais populares baseados em Git.
O CDS suporta nativamente o GitHub, GitLab, Bitbucket Server e Gerrit. O link entre o seu repo Git e o CDS é através de um aplicativo CDS: 1 repositório Git == A CDS APLICATIVO. Através dessa integração, os CDs pressionarão o status de construção de seus compromissos: construção, sucesso ou falhou.
O CDS oferece a possibilidade de clonar de diferentes repositórios Git em um único fluxo de trabalho. Um fluxo de trabalho do CDS pode envolver vários aplicativos diferentes - ou nenhum se você não quiser ter uma conexão com um repo Git.
Capacidade de iniciar serviços efêmeros (um banco de dados, um servidor da web etc.) para apoiar seu trabalho. Isso é particularmente útil ao testar seu código.
Nos CDs, esses serviços são chamados de pré -requisitos de serviço. Você só precisa especificar a imagem do docker correspondente e executar params.
Dê um exemplo simples: você tem um pipeline que cria uma imagem do Docker que contém seu aplicativo. Seu aplicativo precisa de um Redis e um PostgreSQL para funcionar. Você pode, em um trabalho de CDS, colocar três serviços de pré -requisito: um redis, um postgreSQL e seu aplicativo. Os CDs cuidam de fazer uma rede privada entre seus serviços para que possam se comunicar. Seu trabalho de CDS pode, portanto, realizar testes de integração em seu aplicativo, começando com um banco de dados real e um cache real.
Leia: https://ovh.github.io/cds/docs/concepts/requirement/requirement_service/
Um cache remoto é usado por uma equipe de desenvolvedores e/ou um sistema de integração contínua (IC) para compartilhar saídas de construção. Se sua construção for reproduzível, as saídas de uma máquina podem ser reutilizadas com segurança em outra máquina, o que pode tornar as construções significativamente mais rápidas
DOC: https://ovh.github.io/cds/docs/componnts/worker/cache/
Como uma plataforma de nível corporativo, os CDs podem enviar uma ampla gama de seus eventos internos (por exemplo, a compilação finalizada) em um barramento de eventos. Esse fluxo de eventos pode então alimentar outros serviços (relatórios, notificações etc.).
Capacidade de iniciar um fluxo de trabalho manualmente ou com push git ou por meio de um agendador ou através de um webhook. Além do acima, os CDs também podem ser acionados usando um barramento de eventos (Kafka ou RabbitMQ).
Capacidade de gerenciar vários ambientes (por exemplo, dev/prod/estadiamento) de maneira segura com direitos de acesso segregados. Na prática, um ambiente é um conjunto de variáveis que você pode usar em seus fluxos de trabalho.
Com o CDS, você pode usar um pipeline de implantação em seu ambiente de pré -produção e usar o mesmo pipeline de implantação em seu ambiente de produção. A capacidade de implantar para a produção pode ser limitada a um grupo de usuários pré-estabelecido.
Os usuários podem criar grupos e gerenciar usuários em seus grupos. Um grupo pode ter o direito de ler, escrever e executar seus projetos e seus fluxos de trabalho. Você também pode restringir a execução de alguns pipelines em alguns grupos, se desejar.
Se você usa CDs como uma ferramenta CI / CD, provavelmente terá artefatos criados. Os trabalhos do CDS são isolados um do outro, mas você pode passar artefatos de um trabalho para outro usando as ações de download de upload e artefatos de artefatos. No final de um trabalho de CDS, todos os arquivos são excluídos dos trabalhadores. Para persistir artefatos, os CDs podem usar um armazenamento rápido ou um determinado sistema de arquivos (embora não recomendado).
O CDS exibe claramente os resultados de testes de unidade e vulnerabilidades detectadas durante as construções.
Um projeto de CDS é como um inquilino. Todos os usuários podem criar um projeto CDS, este projeto reunirá aplicativos, ambientes, pipelines e, claro, fluxos de trabalho.
Os projetos de CDS são isolados um do outro, mas o mesmo grupo pode ter direitos de acesso a vários projetos, se desejar.
Um modelo de trabalhador é um contexto de execução do trabalhador. Digamos que você precisa executar um emprego que requer Golang v1.11.5. No CDS, você só precisa criar um modelo de trabalhador Go, contendo uma GO na versão 1.11.5. Um modelo de trabalhador pode ser uma imagem do Docker, uma imagem OpenStack ou uma imagem vSphere. Embora os administradores do CDS possam oferecer modelos de trabalhadores compartilhados, os usuários podem criar seus próprios trabalhadores de modelo, se desejarem.
Em um projeto CDS, você pode adicionar integrações como o OpenStack, Kubernetes, etc ... Isso oferecerá recursos dentro de seus fluxos de trabalho. Por exemplo, com a integração do Kubernetes, você pode adicionar seu próprio cluster ao seu projeto CDS e, assim, poder usar a ação do aplicativo de implantação para implantar seu aplicativo recém -construído em seu cluster, em formato de helm, se desejar. É claro que você pode desenvolver suas próprias integrações.
Depois de ler os pontos anteriores, você entendeu: o autoatendimento está em toda parte. Todos os usuários podem criar seus modelos/modelos de fluxo de trabalho/fluxo de trabalho/modelos de fluxo de trabalho ... e executar trabalhos em um ambiente totalmente isolado. Os projetos de CDS são construtores, nos quais você pode adicionar integrações. Tudo isso permite que você tenha apenas uma instância de CDs para toda a sua empresa.
Tudo o que você pode fazer com a interface do usuário está disponível através da interface da linha de comando (CLI), chamada "CDSCTL". O CDSCTL está disponível em todo o sistema operacional: Darwin, FreeBSD, Linux, OpenBSD ... CDSCTL permitirá criar, lançar, exportar, importar seus fluxos de trabalho, monitorar seus CDs e navegar por seus projetos e fluxos de trabalho. Não há necessidade de ir à interface do usuário do CDS ou ao seu gerenciador de repositório para verificar o status do seu commit, git push && cdsctl workflow --track exibirá seu fluxo de trabalho na sua linha de comando.
Você tem necessidades de automação ainda mais avançadas ou o desejo de desenvolver um aplicativo que consulte CDs? A API REST e o SDK permitirão que você desenvolva facilmente seu software.
O CDS é de código aberto desde outubro de 2016. Você pode instalá-lo livremente em sua empresa ou em casa. Alguns tutoriais estão disponíveis para ajudá-lo a iniciar um CDS, Docker-Compose, instalar com binários.
A alta disponibilidade é um ponto muito importante para uma ferramenta CI / CD. O CDS está sem estado, nada é armazenado no sistema de arquivos. Isso possibilita o lançamento de várias APIs de CDs por trás de um balanceador de carga. Assim, você pode dimensionar a API dos CDs para suas necessidades. Ele também permite atualizações de CDs em um dia inteiro sem impacto nos usuários. Na produção @OVH, os CDs podem ser atualizados várias vezes ao dia, sem impactar os usuários ou impedir os trabalhadores do CDS. Pedir a seus usuários que parem de funcionar enquanto atualizavam a ferramenta de entrega contínua seria irônica, não é? ;-)
O CDS expõe nativamente os dados de monitoramento. Você poderá alimentar sua instância Prometheus ou Warp10 usando o Beamium.
Um trabalho de CDS consiste em etapas. Cada etapa é uma ação do tipo embutida (script, checkOutApplication, Artifact Upload/Download ...). Você pode criar suas ações, usando ações existentes - ou desenvolver sua ação como um plug -in. Todos os idiomas são suportados, desde que o idioma suporta GRPC.
O CDS é agnóstico a idiomas e plataformas. Os usuários podem iniciar trabalhos no Linux, Windows, FreeBSD, OS X, Raspberry ... em uma máquina virtual Spawn sob demanda, em um contêiner do Docker, em um host dedicado.
Portanto, se sua empresa usar várias tecnologias, o CDS não será um bloqueador para criar e implantar seu software interno.
Um dos objetivos iniciais dos CDs no OVH: construa e implante 150 aplicativos como contêiner em menos de 7 minutos. Isso se tornou realidade desde 2015. Qual é a chave secreta? On Scale On Demand!
Assim, você pode ter centenas de modelos de trabalhadores e, quando necessário, os CDs iniciarão os trabalhadores usando os incubatórios.
Um incubatório é como uma incubadora, dá à luz os trabalhadores do CDS e o direito à vida e à morte sobre eles.
Vários tipos de incubatório estão disponíveis:
Então, sim, palavras-chave ou não, um OnDemand em escala automática de várias nuvens é uma realidade com CDs :-)
3-cláusulas BSD
