Avaliações e Detalhes do Produto de Shippable

É um dos melhores sites para quem está fazendo algum projeto. É integrado com o GitHub. Painel personalizável. Muito fácil encontrar algo relacionado ao projeto. Docker é o melhor. Eu acho que é melhor usar o Docker às vezes. Análise coletada por e hospedada no G2.com.

Docker tem algumas limitações que deveriam ser removidas. A implantação de projetos às vezes leva mais tempo do que o necessário. Existem pequenos bugs. Análise coletada por e hospedada no G2.com.

É o melhor serviço disponível para desenvolvedores. Dockers é o melhor produto. Há muitos recursos disponíveis no Dockers. Ele usa menos RAM. Tem integrações de vários repositórios como GitHub e GitLab. É fácil implantar nosso projeto. Análise coletada por e hospedada no G2.com.

Dockers não é isolado como VMs. É um pouco caro para aqueles que são iniciantes. Análise coletada por e hospedada no G2.com.

Melhor lugar para estudantes e profissionais que estão trabalhando em projetos. Podemos explorar diferentes projetos. Podemos facilmente implantar nosso projeto. A integração de API é boa. Análise coletada por e hospedada no G2.com.

O painel pode ser melhorado. É um pouco caro conforme a necessidade. A implantação leva mais tempo. A interface gráfica pode ser melhorada. Análise coletada por e hospedada no G2.com.

1. Construa no seu próprio host - Os desenvolvedores podem configurar contêineres Docker em seus próprios servidores e executá-los lá. Assim, você não precisa armazenar seus dados em servidores externos, proporcionando melhor segurança e economia.

2. Arquivo de configuração para descrever builds - Os builds são descritos no arquivo shippable.yml localizado na raiz do seu projeto. Assim, é mais flexível e também pode ser armazenado no seu repositório de código, pois é apenas um arquivo de texto simples. Ou seja, até mesmo o código de configuração pode ser versionado e revisado posteriormente. Se você está vindo do Travis CI, o Shippable lê seu arquivo .travis.yml diretamente, então você pode experimentá-lo diretamente - isso é um recurso bem interessante.

3. Integração com Docker - O Shippable é construído usando Docker, um contêiner Linux popular. Foi originalmente construído usando seu próprio contêiner, mas quando isso começou a se tornar muito complexo, eles mudaram para usar Docker. Desde o início, o Shippable era diferente de outras ferramentas de CI porque, enquanto o Shippable usa um contêiner (Docker), tradicionalmente as ferramentas de CI usavam máquinas virtuais para gerenciar suas cargas de trabalho. Executar no Docker significa que criar e destruir ambientes de build é sempre um prazer e não há chance de sobras de versões anteriores.

4. Ele também suporta testes em vários tempos de execução, versões e ambientes, por exemplo, diferentes versões da linguagem, biblioteca e sistema operacional. Assim, permite testar o código de forma mais completa em muitos cenários. Análise coletada por e hospedada no G2.com.

Atualmente, o Shippable não permite que artefatos de build sejam implantados nativamente no S3. Isso pode ser contornado, no entanto, é uma falha bastante grande quando comparado ao Travis e deve ser corrigido no futuro. Embora seja possível com o arquivo de configuração, é mais difícil de alcançar. Análise coletada por e hospedada no G2.com.

Gosto do Shippable porque é uma solução tudo-em-um para nossas necessidades de construção, empacotamento e implantação. É fácil configurar o arquivo .yml para testar o projeto a partir do código-fonte, construir e empacotá-lo em um binário se os testes passarem e, em seguida, implantá-lo automaticamente em ambientes de teste ou master. Permite etiquetar automaticamente o pacote com informações de versão e armazenar todas as versões para acesso futuro e rollback.

É fácil pensar nele apenas como uma solução de implantação, mas também tem suporte para relatórios de teste e um painel para monitorar o status de testes anteriores e a mudança de porcentagem de cobertura. Isso ajuda a manter um controle rápido sobre muitos projetos sem ter que entrar em todos os projetos e analisar manualmente.

Também gosto que eles tenham um gerenciador de permissões administrativas para controlar o acesso não autorizado de terceiros que você integra ao projeto. Os resultados dos testes podem ser tornados públicos sem armazenar os arquivos de chave publicamente. Análise coletada por e hospedada no G2.com.

No geral, estou impressionado com o número de coisas que eles adicionaram ao longo do tempo, mas gostaria de ter integração com mais alguns serviços como Heroku e DigitalOcean. É possível com SSH, mas uma solução melhor é preferida. Análise coletada por e hospedada no G2.com.

A Shippable oferece aos desenvolvedores a capacidade de automatizar seu fluxo de trabalho, desde a revisão de código até a implementação em produção, tudo sem escrever uma única linha de código. Os scripts de construção e implantação devem ser escritos em um arquivo de configuração separado que é armazenado junto com os arquivos de código. Isso é bom para portabilidade.

A Shippable assume o controle no momento em que um desenvolvedor envia algum código para um repositório, gerenciando todas as etapas necessárias para colocar o código em produção. É tudo automático e nenhuma interação é necessária para construir novas versões, tudo é acionado pelo git push no repositório de código.

Em sua essência, a plataforma oferece aos desenvolvedores um pipeline unificado de entrega de aplicativos baseado em contêineres Docker para sistemas de controle de versão heterogêneos, tornando-a bem adequada para testes unitários, testes funcionais para aqueles que implantam microsserviços, testes de estresse ou testes de segurança. A plataforma também suporta pipelines baseados em script e em interface gráfica. Scripts são mais configuráveis, enquanto os pipelines visuais são melhores para casos mais simples e fornecem mais insight sobre o processo para todos.

Além disso, um recurso chamado Lighthouse permite que os usuários "assinem" uma imagem Docker e sejam notificados de quaisquer alterações, independentemente de quem a gerencia. Se uma alteração for detectada, isso é novamente bom porque os desenvolvedores podem saber que o ambiente de desenvolvimento e não a própria base de código mudou. As compilações acionadas devido a isso devem ser analisadas separadamente, pois é mais provável que seja um problema com as alterações feitas na imagem Docker. Análise coletada por e hospedada no G2.com.

Como é uma solução baseada em Docker, as restrições padrão sobre essas imagens sempre se aplicam. Assim, muitas vezes é difícil encontrar bibliotecas adequadas com a versão necessária. Mesmo assim, como o ambiente é criado e destruído a cada vez, leva algum tempo em cada execução para criar o ambiente. Para soluções não baseadas em Docker, ele pode ser armazenado em cache entre as execuções, proporcionando um tempo de inicialização mais rápido. Análise coletada por e hospedada no G2.com.

Usamos o Shippable como provedor de Integração Contínua para nossa empresa porque gostamos -

A. Trocar o provedor de VM com Azure ou Google APP Engine - A VM padrão fornecida pelo Shippable é compartilhada por natureza e inaceitável para nós em termos de rendimento. Mas, a boa notícia é que eles suportam o uso de outros provedores de VM como Amazon Web Services ou Google APP Engine como backend. Usamos o cluster AWS com testes paralelos para reduzir a duração dos nossos testes.

B. Focado em Docker - Ainda não migramos completamente para o Docker, mas estamos testando um projeto baseado em Docker para um novo cliente e o Shippable parece ter um bom suporte para Docker. Hubs Docker, tanto oficiais quanto outros, são suportados, seu provisionamento de Docker é rápido e gerenciado automaticamente. As configurações do Docker podem ser fornecidas facilmente via UI, sem alterar o código. Análise coletada por e hospedada no G2.com.

1. Nenhum suporte para linguagens de programação mais antigas como C++ e Java é fornecido. Então, escolhemos o Shippable apenas para projetos mais novos.

2. Nenhum provedor de VM próprio - Nossos servidores personalizados não podem ser usados com o Shippable, pois eles não fornecem opções de auto-hospedagem. Preferimos planos empresariais auto-hospedados devido à nossa grande base de desenvolvedores. Análise coletada por e hospedada no G2.com.

Shippable é um dos poucos servidores de CI que suportam apenas testes/desdobramentos baseados em Docker ou containerizados. Portanto, se você não faz parte desse público-alvo, não terá sorte. Mas se você usa Docker, o Shippable é bastante eficaz e traz uma abordagem nova ao processo. Não é muito personalizável, mas cobre bastante terreno com integração de um clique com serviços externos.

Coisas que eu gosto no Shippable

=============================

1. Pipelines de Entrega Contínua Visuais - O método usual para configurar o fluxo na maioria dos servidores de CI é escrever código bash para todas as partes do processo em um único arquivo, mas o Shippable é totalmente o oposto. Você tem uma interface de usuário semelhante a uma linha do tempo onde pode ativar diferentes cartuchos de serviço como bancos de dados, linguagens de programação, serviços de notificação, implantação AWS, etc. Todo o fluxo é dividido em diferentes partes como CI, CD e notificação.

2. Grande variedade de integrações de implantação - Suporta integração direta com AWS Elastic Beanstalk (EB), Heroku, Openshift, DigitalOcean e mais. Como tudo é especificado no pipeline visualmente, eles precisam fornecer adaptadores de implantação para muitos serviços e fazem um ótimo trabalho nisso.

3. Suporta muitos bancos de dados e linguagens dentro do container - Embora o docker seja bom para executar tudo separadamente, seu sucesso depende de quão modulares as imagens podem ser feitas. Se muitas coisas precisam ser instaladas na inicialização do container, será tão lento quanto VMs tradicionais. Portanto, a maioria dos bancos de dados e linguagens são modularizados em cartuchos que você pode ativar externamente.

4. Preços muito acessíveis mesmo para grandes organizações - A conta básica é gratuita, mas testes paralelos para muitos containers ou múltiplas implantações do mesmo pipeline custam $10 para cada item extra. Mesmo após 20 de cada, o preço total chega a cerca de $400, o que é extremamente barato considerando o volume de tais organizações.

5. Pipeline separado para ramos separados em repositórios de código são suportados.

6. Login SSH para depuração de testes é muito útil quando os bugs não são reproduzíveis em máquinas locais. Análise coletada por e hospedada no G2.com.

O maior problema é que o segmento de mercado disponível é muito pequeno, porque o Docker ainda não é tão comum para testes na maioria das organizações. Em sua defesa, é muito orientado ao Docker por escolha e é bastante bom para este segmento de nicho.

Além disso, algumas coisas que não gostei:

1. Suporte muito limitado para serviços de notificação - Apenas Hipchat e Slack são suportados. Seria bom ter suporte para mais alguns como Gitter, Email e IRC.

2. Execução de testes lenta para contas básicas - Testes para um projeto de tamanho decente podem ser muito lentos se trabalhadores paralelos não forem usados.

3. Configuração via UI (pipelines) e arquivo de configuração é um pouco confusa para iniciantes. Análise coletada por e hospedada no G2.com.

Shippable é bastante diferente da concorrência - essa foi a primeira coisa que me veio à mente ao tentar usá-lo. Eles inovaram muito para atrair tanto desenvolvedores individuais quanto empresas.

Gosto de algumas coisas sobre ele:

A. Suporte multilíngue com foco em docker - Shippable não é uma plataforma apenas para docker nem desconhece docker. Ele detecta a linguagem de programação principal do projeto muito rapidamente e, se o projeto for baseado em docker, ele também captura as configurações do docker e inicia um contêiner para o processo de implantação. É bastante fácil supor erroneamente que Shippable é apenas para projetos docker, mas não é - ele apenas se integra muito bem com eles. O suporte a linguagens é bastante bom com python, node.js e outros no menu.

B. Abordagem BYOH (Traga seu próprio host) - É aqui que o casamento entre empresas e usuários individuais entra em jogo - Se você não gosta das VMs padrão fornecidas pelo Shippable como sua plataforma de teste e construção, você pode trocá-las por qualquer instância do Azure, DigitalOcean, Google App Engine, Google Compute Engine ou Heroku para uma experiência personalizada. Você também pode usar sua arquitetura local junto com as hospedadas para obter o melhor dos dois mundos. Os desenvolvedores querem usar os serviços populares como provedores de VM e as empresas querem usar suas próprias máquinas para a melhor experiência.

C. Depuração - Acesso completo à saída do console para cada teste/construção e acesso SSH a essas máquinas realmente ajudam na depuração quando os testes falham por algum motivo desconhecido.

D. Autoconfiguração a partir de arquivos de configuração de teste populares - Ao configurar as coisas, eu apenas ativei a construção para um projeto sem configurar nada para o Shippable. Este projeto já tinha Travis e Circle CI configurados para testes adequados. Agora, eu esperava razoavelmente que essa construção falhasse com algo como "Nenhum teste encontrado", mas para minha surpresa, ele reconheceu um desses arquivos de configuração e executou todos os comandos de teste com sucesso. Embora os resultados dos testes não tenham sido coletados, foi uma surpresa agradável para mim. Análise coletada por e hospedada no G2.com.

Shippable é, no geral, bastante bom, mas acho que ainda há algumas pequenas deficiências que precisam ser abordadas -

A. A VM padrão foi muito lenta para iniciar, levou mais de 2 minutos. Isso é bastante lento em comparação com a concorrência.

B. Bancos de dados e outros serviços são difíceis de instalar em ambientes de teste não dockerizados.

C. Nem todas as partes dos arquivos de configuração de teste padrão são automaticamente reconhecidas pelo Shippable. Por exemplo, apt-get <packagename> não é detectado automaticamente. Análise coletada por e hospedada no G2.com.

Eu gosto da velocidade de construção, pois é baseada no Docker e na sua integração com web hooks com o BitBucket para relatar o status da construção, que é postado pelo BitBucket no Slack. Análise coletada por e hospedada no G2.com.

Às vezes, as compilações ficam presas na etapa de provisionamento de nós e geralmente leva muito tempo para concluir essa etapa. Análise coletada por e hospedada no G2.com.