Githawk: Alternativas para Buddybuild?

Para outra opção auto-hospedada, TeamCity (https://www.jetbrains.com/teamcity)?

Normalmente, a fila de trabalhos do CircleCI para projetos de código aberto é muito menos lotada do que o TravisCI.

Meus $ 0,02 de gerenciamento de alguns dos repositórios RxSwiftCommunity.

Travis é um lixo absoluto (ou se tornou ao longo do tempo).
O enfileiramento é intolerável e retarda os esforços de desenvolvimento (esperar 50 minutos por uma compilação dos anos 90 é inaceitável) e a configuração é relativamente irritante.

Estamos movendo lenta mas seguramente a maioria dos repositórios para CirlceCI e estamos muito felizes com isso. O enfileiramento é realmente rápido e justo, e a configuração é relativamente fácil.

Também ouvi ótimas coisas sobre Bitrise nesse sentido.

Que pena sobre o BB, é interessante ficar de olho nele, pois não acho que a Apple o mataria - mas sim

Tinha experiência com uma versão mais antiga do Jenkins, como uma ferramenta é definitivamente capaz, mas exigiria bastante manutenção / configuração e na arte de manter as coisas abertas e colaborativas provavelmente não é a melhor coisa honestamente

Além disso, se escolhermos outro "grande" provedor, corremos o mesmo risco de ser simplesmente varrido por outra empresa que joga Banco Imobiliário

Eu estaria inclinado a tentar o Bitrise, meus 2 centavos

Estou obviamente tendencioso;) mas algo assim não vai acontecer com o App Center.
Caso tenha interesse, entre em contato.

cc @Palleas

_{Enviado com GitHawk}

Https://Buildozer.io suporta iOS e Android. (divulgação: sou um de seus fundadores)

Temos usado o CircleCI em todos os projetos Artsy iOS que exigem um mac para CI - as filas do OSS não têm sido um problema como o travis '

Passei o dia inteiro testando o Bitrise e o App Center. Até agora, eles não parecem tão fáceis de usar e mágicos quanto o BuddyBuild ...
Estou feliz pela equipe do BB (e orgulhoso por estar em Vancouver também), mas muito chateado como usuário ...
O BuddyBuild era um daqueles serviços que simplesmente funcionam, quase sem configuração necessária.

Eu realmente gostei da maneira como o Buddybuild funciona. Eu cansei o Circle CI antes, mas há algumas coisas a serem observadas aqui é que ele usa Fastlane para assinar e implantar para Test Flight, Automatic Signing não pode ser usado. tem que usar "Manual"

Eu configurei algum tempo para bater um papo com

Verifique https://buildkite.com/ eles oferecem uma conta gratuita para OSS

Grande fã de bitrise aqui. Nós o usamos muito com nossa solução https://www.appaloosa-store.com/

@sregg, o que exatamente não estava funcionando para você no App Center? Eu ficaria feliz em ajudar com qualquer coisa específica do Build.

@derpixeldan por exemplo, a integração com o Slack é toda manual usando webhooks comparada a apenas uma caixa de seleção com BB. Além disso, não há como iniciar um número de compilação a partir de um número especificado (ou seja, meu número de compilação atual no BB). Por fim, assinar o aplicativo iOS não parecia tão simples quanto o do BB (acho que só dei a eles meu nome de usuário / senha da Apple id e eles gerenciaram o certificado e o provisionamento automaticamente)

Eu sou o gerente de engenharia da Microsoft para o App Center Build. Temos uma grande equipe fazendo melhorias todas as semanas e estamos comprometidos com o suporte multiplataforma.

@sregg um ótimo feedback e acho que melhorias em todas essas áreas estão em nosso backlog.

Sinta-se à vontade para me enviar uma mensagem no Twitter em https://twitter.com/0xlukekim com quaisquer questões / preocupações / comentários.

Devo dizer que fiquei muito impressionado com o App Center, principalmente no sentido "meta" de:

• Os esforços de desenvolvimento que a Microsoft está colocando nisso.
• A propriedade e o carinho que alguns funcionários demonstram ao comentar aqui.
• Eu vi isso em ação na AltConf ano passado e parecia muito bom.

Não tenho experiência suficiente com isso, mas parece ser um competidor digno também :)

Olá a todos, sou o Viktor de https://www.bitrise.io (CTO e cofundador).

Obrigado a todos pela recomendação, isso significa muito para nossa equipe!

Só queria dizer olá e garantir que estamos ouvindo, sinta-se à vontade para nos enviar um ping a qualquer momento por meio de qualquer um de nossos canais de suporte e terei prazer em responder a quaisquer perguntas que você tenha aqui também!

Haha, acho que podemos começar a guerra de lances agora 😄

Meu GitHawk traz todos os CIs para o quintal 🤓

Há também https://buddy.works que não usei o serviço deles, é difícil dizer se eles são bons. Eles definitivamente têm um nome legal; P

Mudei do BuddyBuild para o Bitrise (realmente queremos um lugar para o nosso iOS e Android). Foi necessária alguma leitura dos documentos e também alguns dos repositórios git da etapa, mas foi bem tranquila, demorou cerca de um dia para fazer outras coisas.

@sregg Apenas para mencionar que usamos a etapa "Ajustar BuildNumber" para + = 640, já que usamos para versionCode e estávamos implantando automaticamente a partir do BB.

As principais diferenças que encontrei com o Bitrise em relação ao BuddyBuild (além de quase tudo ser baseado em GUI no BB) foi dividir a compilação do Gradle em várias etapas. O BuddyBuild construiria (possivelmente com mais eficiência) tudo o que você pediria e, em seguida, retiraria o material relevante para, digamos, e-mails de implantação ou publicação na Play Store, com o Bitrise você tem algumas opções que posso ver: 1. dividir em várias etapas Build / Gradle, por exemplo, para testes de IU / Android, para suas compilações de teste [2x3 = 6 variantes para nós], uma para seus artefatos de implantação da App / Play Store, com algumas etapas de limpeza entre (por exemplo, eu mudo a pasta de implantação depois de evitar que e-mails sejam enviados onde os filtros não são suficientes) ... ou 2. sinta-se confortável com o script bash e tenha uma etapa de script que divide as variáveis ​​ENV do mapeamento de tubos para que possam ser usadas mais facilmente nas etapas posteriores.

Também seria bom ter mais exemplos, configurando as mensagens slack para incluir algo como as que o BB enviou por padrão, por exemplo, é bom poder personalizar, mas geralmente queremos apenas voltar a escrever o código.

O outro seria recursos que não estávamos usando, gerenciamento de testador (usamos Play Store Alpha e TestFlight) e agitação para registro de travamento / falha (preferimos Firebase).

Um dos recursos realmente interessantes é poder não apenas visualizar e editar seu fluxo de trabalho como um arquivo .yml, mas fazer o download e executá-lo localmente com a CLI.

Para ser sincero, dá muito mais trabalho do que estávamos acostumados, esse é o ponto de pagar mensalmente, certo? Mas é praticamente uma coisa única e o bônus é a personalização extra. No geral, está fazendo o trabalho muito bem e por um bom preço. Estou feliz com essa mudança. Tenho certeza de que o CircleCI também é bom (usamos isso para o nosso back-end).

Também é importante notar que todo o infra do bitrise é OSS - https://github.com/bitrise-io/bitrise.io

Obrigado @richardleggett pelo feedback, irei discutir isso com a equipe!

Especialmente o Slack - eu acho que já deveria ter uma mensagem padrão "mais elaborada" (mais útil), em vez de exigir que você crie sua mensagem de "sonho" logo após interromper a etapa pela primeira vez. A flexibilidade é importante, mas também o valor padrão / experiência de configuração (e velocidade). Você pode ajustar a mensagem depois disso de qualquer maneira, então não há problema em tornar o padrão mais detalhado.

Gradle: vai discutir isso com a equipe de ferramentas também, obrigado pelo destaque!

Eu tenho chutado a lata sobre isso (aumentando lentamente minha ansiedade). Desejo criar um link para esta postagem do blog explorando alternativas, caso haja mais informações lá.

Eu quero passar algum tempo com @orta e @krausefx enquanto estiver na cidade para discutir minha visão "estrela do norte" para automatizar este projeto (além de apenas CI). Apresentarei um relatório assim que reunir energia para realmente trabalhar nisso.

Obrigado pela atualização neste @rnystrom. Eu entendo você. 😕

@rnystrom, obrigado pela postagem no blog e lamento saber que você teve problemas com a configuração da distribuição no bitrise. Não tenho certeza se você viu, mas agora construímos o provisionamento automático para assinatura de código, que uma vez configurado pode gerenciar os arquivos de assinatura do iOS para você automaticamente: https://blog.bitrise.io/ios-auto-provision-step

De qualquer forma, gostaria apenas de agradecer por experimentar a taxa de bits e informar que estamos sempre dispostos a ajudar, caso você tente novamente a taxa de bits. Sinta-se à vontade para me pingar em qualquer lugar, por exemplo, em nosso Slack (http://chat.bitrise.io).

@viktorbenei Por que vale a pena, essa não é a postagem do blog de Ryan!

Ai, que pena, ainda é muito cedo aqui 😅 Desculpem senhores e obrigado @Sherlouk !

Na verdade, comecei um trabalho com a Bitrise ontem à noite. Apresentarei um relatório de volta!

_{Enviado com GitHawk}

Bitrise build é verde! Tão fácil de configurar quanto o BB. Acho que temos um vencedor.

_{Enviado com GitHawk}

Fico feliz em ouvir @rnystrom ! :)

Na verdade, a configuração inicial deve ser bastante suave, semelhante ao BB. A principal diferença é a configuração da IU depois disso. A abordagem do BB era fornecer uma IU simples, o que implica que certas coisas podem não ser possíveis / não podem ser alteradas, enquanto nos concentramos principalmente na flexibilidade, para permitir que você especifique cada aspecto do processo se desejar (mas isso vem com um certo complexidade e curva de aprendizagem mais íngreme). Sabemos que essa curva de aprendizado pode ser demais, especialmente para projetos de hobby e estamos trabalhando para melhorá-la; algumas coisas planejadas para este ano para facilitar a implementação de configurações, etc.;)

https://appcenter.ms parece promissor

Em nome da transparência, é aqui que estamos no momento: eu tenho o Bitrise e o App Center CI construindo o GitHawk. Ambos os serviços são muito fáceis de usar, então eu quero tentar usar ambos para entregar várias compilações beta e uma única compilação da App Store, documentando meu processo.

Aqui estão meus pensamentos iniciais

Bitrise

Prós

• Ótimo suporte (h / t @viktorbenei)
• Construções bem rápidas
• Implantar via fastlane
• Personalização extrema e granularidade das etapas de construção
• A plataforma é de código aberto (ish)
• Enviar automaticamente as compilações para o ITC de master (eu _ amo_ isso)

Contras

• Nenhum plano gratuito de código aberto (_ainda_)
• Startup (pode ser adquirido ou desaparecer)

Central de aplicativos

Prós

• As compilações são _muito_ rápidas
• Menos personalização = mais simplificação
• Adaptado para implantação iOS / Android
• @TroubleMakerBen rocks 😄
• Apoiado pela Microsoft
  
  
  
  • Provavelmente não irá embora logo
  
  
  • ++ recursos
  
  

Contras

• Nenhum plano gratuito de código aberto (_ainda_)
• Requer um alvo compartilhado para construir
• Implementação automatizada tbd (confirmada a sua vinda)
• Muitas coisas que não usaremos (por exemplo, não preciso do SDK do App Center)
• A saída do registro é _muito verbosa_, difícil de encontrar erros de compilação
• Sem integração de status do GitHub

Obrigado por compartilhar @rnystrom ! Apenas uma correção, o componente de serviço da web de bitrise não é de código aberto, portanto, não é possível hospedar a API e a interface de usuário da web (ainda;)). Todas as ferramentas usadas para executar a configuração (o editor de fluxo de trabalho, o runner CLI, ...) são de código aberto, então você pode baixar a configuração de compilação e executá-la em seu próprio Mac (ou em qualquer Mac / Linux), semelhante a fastlane.

Só uma pergunta, para efeito de comparação

Bitrise: Contras: nenhum plano gratuito de código aberto (ainda)

O AppCenter tem um plano de código aberto? Pode ter perdido, AFAIK eles não têm um também. Estou realmente curioso, pois não consegui encontrar nada relacionado no site do appcenter.

Sem integração de status do GitHub

Isso é um grande ☹️

@viktorbenei será atualizado! Ainda não

_{Enviado com GitHawk}

Ei pessoal,

Obrigado pelo feedback e pela comparação. Eu gosto disso e nossos PMs estão olhando para este tópico.

Implementação automatizada tbd (confirmada a sua vinda)

No momento, estamos trabalhando muito para tornar a distribuição melhor. Fique ligado.

O AppCenter tem um plano de código aberto? Pode ter perdido, AFAIK eles não têm um também. Estou realmente curioso, pois não consegui encontrar nada relacionado no site do appcenter.

Ainda não temos um plano de OSS.

Felicidades a todos e tenham um bom final de semana!

Isso pode ser relevante agora https://github.com/fastlane/ci 👍

@KrauseFx Eu vi isso e estou muito feliz com isso.

Por que pedir recursos se nós, como comunidade, podemos desenvolvê-los? Além disso, o Google está apoiando isso? não poderia pedir muito mais.

Realmente ansioso para contribuir com código para isso à medida que progride e aplicá-lo ao nosso fluxo de trabalho conforme ele amadurece.

Obrigado por tudo que vocês estão fazendo pela comunidade!

@KrauseFx jogador 3 entrou no jogo

_{Enviado com GitHawk}

lolz

Eu não acho que o App Center suporta sintaxe por commit [ci skip] like

@dkhamsing infelizmente não (ainda).

Uma vantagem real para buddybuild que eu adorei foi a maneira como eles aparecem antes / depois / diffs nos resultados do teste se um teste de unidade FBSnapshotTestCase produziu uma imagem inesperada.

Alguém sabe se algum desses outros sistemas possui um recurso semelhante?

O App Center é compatível com a criação de uma solicitação pull? Estou muito confuso cc @TroubleMakerBen

@dkhamsing sim!

editar: deixa pra lá 🙊

_{Enviado com GitHawk}

O @dkhamsing App Center oferece suporte para construir em PUSH, mas não em PR (construir em mesclagem), ainda.

Ah, entendo. Thx Ryan, Ben 😊

_{Enviado com GitHawk}

Depois de ler este tópico, parece ser uma corrida de dois cavalos: Bitrise e App Center. Ainda assim, ninguém tocou no assunto de testes de IU: adorei como no BB, com apenas alguns cliques, você pode executar testes de expresso em um dispositivo virtual. Alguma das duas plataformas em discussão suporta isso?

https://docs.microsoft.com/en-us/appcenter/test-cloud/

_{Enviado com GitHawk}

O teste do

Na verdade, estamos tentando identificar uma nova solução de CI.

• AppCenter : semelhante ao bb, mas não fornece suporte de RP, acho que é mais voltado para o pessoal de gerenciamento, também os logs não fornecem uma pilha se alguma tarefa falhar.

• Bitrise: Muito configurável, oferece muitas "etapas" abertas como codecoverage, implantar, assinar, unitTest, UITest, construir, entregar, limpar e customizar, porque você tem a capacidade de configurá-lo, só ficou um pouco confuso com arquivos .yaml, você pode acionar etapas com Push, PR, etc.

• Nevercode Muito configurável, você pode selecionar entre tarefas gradlew por ramo, construir PR, sem plano gratuito.

Acho que pelo menos o Bitrise oferece muitos recursos que podemos explorar!

A partir do link postado acima sobre testes no App Center

1. Reveja os conceitos básicos
   Compreender os principais conceitos da experiência do Test Cloud melhora a facilidade de uso, navegação e comunicação com suporte. É recomendável se familiarizar com esses conceitos antes de executar seus primeiros testes.

Que diabos ... Não quero revisar nenhum conceito, central ou não, só quero que funcione com 2 cliques como funcionou no BB :( Não tenho 10 horas para mergulhar em fazer isso funcionar, Eu sou um programador, não um engenheiro devops ...

Sim, a documentação do App Center pode ser simplificada

_{Enviado com GitHawk}

@acristescu

Depois de ler este tópico, parece ser uma corrida de dois cavalos: Bitrise e App Center. Ainda assim, ninguém tocou no assunto de testes de IU: adorei como no BB, com apenas alguns cliques, você pode executar testes de expresso em um dispositivo virtual. Alguma das duas plataformas em discussão suporta isso?

Não (ainda) um único clique, mas também mais poderoso de duas maneiras: https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

Estamos trabalhando para tornar a configuração mais fácil (é por isso que ainda é "beta", não por falta de funcionalidade;)).

@acristescu @dkhamsing Estamos cientes! Continue enviando feedback.

@viktorbenei Vou tentar, mas, meu Deus, esse estilo de arte é

Não tem problema, @acristescu , eu definitivamente entendo o que você

Decidi experimentar ambos com um repositório simples (https://github.com/acristescu/GreenfieldTemplate) e ver onde chego. Até agora, experimentei o App Center e encontrei alguns empecilhos:

• resolvido (não foi possível encontrar as ferramentas de compilação do gradle!), você deve adicionar manualmente o repositório google() ao gradle do seu projeto
• ele reiniciou o número da compilação de 1, enquanto eu já lancei na Play Store a 42, o Google simplesmente rejeitará a compilação!)
• Não consegui descobrir como testar em um dispositivo virtual gratuitamente, apenas em dispositivos reais com um teste gratuito de 30 dias.
• Não tenho certeza se ele executou os testes de unidade porque

##[warning]No test result files matching /Users/vsts/agent/2.127.0/work/1/s/**/build/test-results/TEST-*.xml were found, so publishing JUnit test results is being skipped.

Não tenho certeza do que se trata ...

Bitrise: No lado positivo, a configuração foi tão fácil, embora eu ache que se eu precisar mudar alguma coisa, preciso abrir um arquivo yml e mexer nele (atualização: encontrei uma coisa chamada editor de fluxo de trabalho. Parece assustador, mas poderoso) . Snags:

• nunca me perguntou qual variante construir e escolheu a errada. Eu queria prodRelease mas por alguma razão ele decidiu construir exatamente os outros dois mockDebug e prodDebug . Não consigo encontrar onde mudar isso, mas tenho certeza de que deve haver um.
• a compilação levou mais tempo, 4 minutos em vez de 2 minutos e 16 para o centro de aplicativos. Talvez seja por causa do problema acima?
• não vejo nenhuma menção de testes junit em qualquer lugar nos logs. Duvido que os tenha executado. Não é óbvio como adicioná-los, talvez em algum lugar no editor de fluxo de trabalho? (atualização mexeu com o Editor de fluxo de trabalho por cerca de 10 minutos e o encontrei. Pontos de bônus por me permitir a liberdade de escolher qual test alvo executar)
• não tenho certeza de qual ID de compilação foi usado, como posso ver isso?

Obrigado por postar estes

_{Enviado com GitHawk}

Obrigado @acristescu pelo feedback detalhado, nós o apreciamos muito. Especialmente no aviso para arquivos de relatório de teste JUnit no App Center, isso não está afetando sua execução de teste real e deve ser corrigido em breve.
Deixe vir!

Levei duas horas, mas consegui convencer o app center a fazer o upload para o Google Play. No entanto, não consigo convencê-lo a fazer isso automaticamente, tive que baixar o APK assinado do centro de aplicativos e, em seguida, carregá-lo de volta na seção de implantação / lojas (!) Para fazê-lo funcionar. Parece terrivelmente complicado, o que estou fazendo de errado?

PS: Para piorar a situação, o BuddyBuild foi implantado várias vezes no mesmo intervalo de tempo, pois esqueci de desativá-lo no início e ele funciona automaticamente sem qualquer intervenção humana ...

Olá @acristescu ,

Re: https://github.com/rnystrom/GitHawk/issues/1330#issuecomment -368228417

nunca me perguntou qual variante construir e escolheu a errada. Eu queria prodRelease, mas por alguma razão ele decidiu construir exatamente os outros dois mockDebug e prodDebug. Não consigo encontrar onde mudar isso, mas tenho certeza de que deve haver um.

De fato, nosso scanner atual adicionará uma etapa Gradle Runner, com assembleDebug configurado para o fluxo de trabalho básico. Percebemos que isso pode não ser direto o suficiente, mas em resumo, se você deseja construir prodRelease , a tarefa do gradle é assembleProdRelease . Se você deseja executar o lint, a tarefa do gradle é lint . Você pode fazer tudo isso com a etapa Gradle Runner; na verdade, o gradle pode lidar com várias tarefas, portanto, para executar lint e assembleProdRelease você também pode especificar isso como a tarefa: lint assembleProdRelease que fará ambos.

Estamos trabalhando em novas etapas e novas configurações padrão do scanner que tornarão isso mais fácil, com etapas mais específicas (por exemplo, uma etapa "Lint" que executa a tarefa gradle lint , em vez de exigir que você defina essa tarefa em a etapa "Gradle Runner") 😉

a compilação levou mais tempo, 4 minutos em vez de 2 minutos e 16 para o centro de aplicativos. Talvez seja por causa do problema acima?

Na verdade, esse parece ser o caso, já que assembleDebug provavelmente gera 2 APKs / variantes separados no seu caso, em vez de um único "ProdRelease".

não vejo nenhuma menção de testes junit em qualquer lugar nos logs. Duvido que os tenha executado.

Especifique test como a entrada da tarefa Gradle da etapa Gradle Runner, que executará seus testes - ou adicione a etapa Gradle Unit Test, que é configurada para executar essa tarefa Gradle por padrão.

não tenho certeza de qual ID de compilação foi usado, como posso ver isso?

Se você quer definir se definimos o número da compilação como o número da compilação bitrise.io: por padrão, não o fazemos, você pode fazer isso adicionando a etapa Change Android versionCode e versionName, por exemplo.

Obrigado mais uma vez por seus comentários, estamos ouvindo e já programamos para melhorar esses pontos da experiência de configuração! ;)

Discussão incrível. Tenho achado difícil encontrar uma alternativa ao BuddyBuild que ofereça suporte a Cartago.

Eu olhei para Nevercode, eles só suportam cocoapods.

Acredito que o App Center oferece suporte a Cartago.

Quaisquer outros?

@jamesone

Acho que a melhor opção para você poderia ser o Bitrise, eles fornecem uma plataforma como pipelines bitbucket , também você pode configurar com base em suas necessidades usando o Steps.

Na verdade mudamos de bb para bitrise, estamos usando Android e iOS e está tudo perfeito!

Impressionante @cbedoy O que você fez sobre as compilações instaláveis ​​que o buddybuild fornece para todos os seus branches? O Bitrise tem integração OU suporte para isso?

Você pode acionar fluxos de trabalho (muitas _etapas_) ao enviar, criar um PR ou tag.

Além disso, você pode agendar buils por ramo.

Você deve verificar:

https://devcenter.bitrise.io/bitrise-cli/workflows/
https://devcenter.bitrise.io/bitrise-cli/steps/

Quando você entende como funciona o bitrise pode criar fluxos de trabalho com base no que você precisa, ou seja, eu quero um fluxo de trabalho onde apenas executar o teste de unidade se alguém criar um PR ou quero um fluxo de trabalho onde construir e gerar o .ipa quando o master foi marcado.

Bitrise é algo como imagens docker onde você pode escolher um _steps_ de terceiros para executar unitTest, CodeCoverage ou Arquivar e implantar.

Homem incrível! Parece muito interessante. Vou dar uma olhada nisso.