Githawk: Buddybuild의 대안?

다른 자체 호스팅 옵션의 경우 TeamCity(https://www.jetbrains.com/teamcity)?

일반적으로 오픈 소스 프로젝트의 CircleCI 작업 대기열은 TravisCI보다 훨씬 덜 혼잡합니다.

RxSwiftCommunity 저장소 중 일부를 관리하여 0.02달러를 받았습니다.

Travis는 절대 쓰레기입니다(또는 시간이 지남에 따라).
큐잉은 참을 수 없고 개발 노력을 느리게 하며(90년대 빌드를 위해 50분을 기다리는 것은 용납할 수 없음) 구성이 상대적으로 성가십니다.

우리는 느리지만 확실하게 대부분의 저장소를 CirlceCI로 옮기고 있으며 매우 만족하고 있습니다. 대기열은 정말 빠르고 공정하며 구성은 비교적 간단합니다.

그런 의미에서 Bitrise에 대한 좋은 소식도 들었습니다.

BB에 대한 엄청난 수치심, Apple이 그것을 죽일 것이라고 생각하지 않으므로 계속 주시하는 것이 흥미로울 것입니다.

이전 버전의 Jenkins에 대한 경험이 있는 도구로서 확실히 가능하지만 유지 관리/구성이 상당히 많이 필요하며 개방적이고 협업적인 상태로 유지하는 기술에서 정직하게 가장 좋은 것은 아닐 것입니다.

또한 우리가 다른 "큰" 제공업체에 간다면 모노폴리를 플레이하는 다른 회사에 의해 휩쓸리는 것과 같은 위험을 감수해야 합니다.

내 2센트인 Bitrise를 사용해 보고 싶습니다.

나는 분명히 편향되어 있습니다 ;) 그러나 이와 같은 일은 App Center에서 일어나지 않을 것입니다.
관심이 있으시면 연락주세요.

cc @팔레아스

_{GitHawk 와 함께}

Https://Buildozer.io 는 iOS와 Android를 모두 지원합니다. (공개: 나는 설립자 중 한 명입니다)

우리는 CI용 Mac이 필요한 모든 Artsy iOS 프로젝트에서 CircleCI를 사용하고 있습니다. OSS 대기열은 travis와 같은 문제가 되지 않았습니다.

나는 하루 종일 Bitrise와 App Center를 사용해 보았습니다. 지금까지는 BuddyBuild처럼 사용하기 쉽고 마법처럼 보이지 않습니다...
나는 BB 팀에 만족하지만(밴쿠버에 있기 때문에 자랑스럽기도 함) 사용자로서 매우 화가 납니다...
BuddyBuild는 구성이 거의 필요 없이 바로 작동하는 서비스 중 하나였습니다.

Buddybuild가 작동하는 방식이 정말 마음에 들었습니다. 이전에 Circle CI에 지쳤지만 여기서 주의할 점이 몇 가지 있습니다. Fastlane을 사용하여 서명하고 Test Flight에 배포하고 자동 서명을 사용할 수 없다는 것입니다. "수동"을 사용해야 합니다

@TroubleMakerBen 과 채팅할 시간을 설정했습니다. AppCenter _looks_ 정말 멋집니다. 그것에 대해 자세히 알아보고 다시 보고할 것입니다!

https://buildkite.com/ 을 확인

여기 bitrise의 열렬한 팬. 우리 솔루션 https://www.appaloosa-store.com/ 에서 많이 사용합니다.

@sregg App Center에서 정확히 무엇이 당신을 위해 작동하지 않았습니까? 특정 빌드에 대해 도움이 되었으면 합니다.

예 를 들어

저는 Microsoft에서 App Center Build를 담당하는 엔지니어링 관리자입니다. 우리는 매주 개선하는 훌륭한 팀을 보유하고 있으며 다중 플랫폼 지원을 위해 최선을 다하고 있습니다.

@regg 훌륭한 피드백이 있고 이러한 모든 영역의 개선이 백로그에 있다고 생각합니다.

또한 문제/우려/피드백이 있는 경우 Twitter( https://twitter.com/0xlukekim) 에서 언제든지 DM을 보내주세요.

저는 주로 "메타"라는 의미에서 App Center에 깊은 인상을 받았습니다.

• 마이크로소프트가 들이고 있는 개발 노력.
• 일부 직원은 여기에 댓글을 달아 주인의식과 배려를 보여줍니다.
• 나는 작년에 AltConf에서 그것을 실제로 보았고 꽤 멋져 보였습니다.

경험이 많지는 않지만 충분히 경쟁력이 있는 것 같습니다. :)

안녕하세요 여러분, 저는 https://www.bitrise.io (CTO 및 공동 설립자)의 Viktor입니다.

추천해주신 모든 분들께 감사드립니다. 저희 팀에 큰 의미 가 있습니다 !

그냥 안녕 👋 이라고 말하고 싶었고 우리가 당연히 듣고 있다는 것을 확인하고 지원 채널을 통해 언제든지 핑을 보내주세요. 여기에서 질문에 답변해 드리겠습니다!

하하, 이제 입찰 전쟁을 시작할 수 있을 것 같아요 😄

내 GitHawk는 모든 CI를 마당으로 가져옵니다 🤓

https://buddy.works 도

저는 BuddyBuild에서 Bitrise로 옮겼습니다(우리는 iOS와 Android를 위한 한 곳을 정말로 원합니다). 문서와 단계의 git repos 일부를 읽는 데 약간의 시간이 걸렸지만 다른 작업을 수행하는 데 하루 정도 걸렸고 꽤 순조롭게 진행되었습니다.

@sregg "Adjust BuildNumber" 단계를 versionCode 하고 BB에서 자동 배포했기 때문에 += 640으로 사용한다는 것을 언급하기만 하면 됩니다.

BuddyBuild를 통한 Bitrise에서 발견한 주요 차이점(BB에서 GUI 기반의 거의 모든 것을 제외하고)은 Gradle 빌드를 여러 단계로 나누는 것입니다. BuddyBuild는 (더 효율적일 수 있음) 사용자가 요청하는 모든 것을 구축한 다음 배포 이메일 또는 Play 스토어에 게시와 같은 관련 항목을 가져옵니다. Bitrise를 사용하면 다음과 같은 몇 가지 선택 사항이 있습니다. 1. 분할 여러 빌드/Gradle 단계(예: UI/Android 테스트용), 테스트 빌드용[2x3=6 변형], App/Play 스토어 배포 아티팩트용 하나, 그 사이에 일부 정리 단계 포함(예: 필터가 충분하지 않은 곳에서 이메일이 나가는 것을 방지)... 또는 2. bash 스크립트에 익숙하고 파이프 맵 ENV 변수를 분할하는 스크립트 단계가 있어 이후 단계에서 더 쉽게 사용할 수 있습니다.

예를 들어 BB가 기본적으로 보낸 것과 같은 것을 포함하도록 여유 메시지를 설정하는 더 많은 예제가 있으면 좋을 것입니다. 예를 들어 사용자 정의할 수 있으면 좋지만 일반적으로 코드 작성으로 돌아가고 싶습니다.

다른 하나는 우리가 사용하지 않는 기능, 테스터 관리(Play Store Alpha 및 TestFlight 사용), 충돌/충돌 로거용 흔들림(Firebase 선호)입니다.

정말 멋진 기능 중 하나는 워크플로를 .yml 파일로 보고 편집할 수 있을 뿐만 아니라 CLI를 사용하여 로컬에서 다운로드하고 실행할 수 있다는 것입니다.

솔직히 예전보다 훨씬 더 많은 작업이 필요합니다. 그게 월세를 내는 요점이죠? 그러나 그것은 거의 일회성이며 보너스는 추가 사용자 정의 가능성입니다. 전반적으로 매우 훌륭하고 좋은 가격에 작업을 수행하고 있습니다. 이 스위치에 만족합니다. CircleCI도 훌륭하다고 확신합니다(우리는 이를 백엔드에 사용합니다).

Bitrise의 전체 인프라는 OSS입니다. https://github.com/bitrise-io/bitrise.io

피드백을 보내 주신 @richardleggett 에게 감사드립니다. 이 문제에 대해 팀과 논의하겠습니다!

특히 Slack 하나 - 첫 번째 단계에 빠진 직후 "꿈" 메시지를 생성하도록 요구하는 대신 "더 멋진"(더 유용한) 기본 메시지를 갖는 것이 이제 너무 늦었다고 생각합니다. 유연성도 중요하지만 기본값/설정 경험(및 속도)도 중요합니다. 어쨌든 그 후에 메시지를 조정할 수 있으므로 기본값을 더 장황하게 만드는 데 문제가 없습니다.

Gradle: 툴링 팀과도 논의할 예정입니다. 강조해 주셔서 감사합니다!

나는 이것에 대해 깡통을 차고 있습니다(천천히 내 불안을 증가시킴). 더 많은 정보가 있는 경우 대안을 탐색하는 이 블로그 게시물 에 링크하고 싶었습니다.

나는 이 프로젝트를 자동화하기 위한 나의 "북쪽 별" 비전에 대해 논의하기 위해 @orta 및 함께 시간을 보내고 싶습니다. 실제로 이것에 대해 작업하기 위해 에너지를 소집하면 다시 보고할 것입니다.

이 @rnystrom에 대한 업데이트에 감사드립니다. 나는 당신을 느낀다. 😕

@rnystrom 은 블로그 게시물에 감사하고 https://blog.bitrise.io/ios-auto-provision-step

어쨌든, bitrise를 사용해 주셔서 감사합니다. 그리고 bitrise를 다시 시도할 경우를 대비하여 항상 기꺼이 도와드리겠습니다. Slack(http://chat.bitrise.io)과 같은 곳에서 언제든지 저에게 핑을 보내주십시오.

@viktorbenei 그만한 가치가 있는 것은 Ryan의 블로그 게시물이 아닙니다!

앗, 맙소사, 여기는 아직 이른 아침이야 😂 미안하고 고마워 @Sherlouk !

실제로 어제 밤 Bitrise 작업을 시작했습니다. 다시보고합니다!

_{GitHawk 와 함께}

Bitrise 빌드는 녹색입니다! BB만큼 설정이 쉽습니다. 승자가 있다고 생각합니다.

_{GitHawk 와 함께}

@rnystrom 을 듣게 되어

실제로 초기 설정은 BB와 유사하게 매우 원활해야 합니다. 주요 차이점은 그 이후의 구성 UI입니다. BB의 접근 방식은 원하는 경우 프로세스의 모든 측면을 지정할 수 있도록 유연성에 주로 초점을 맞추면서 특정 사항이 불가능하거나 변경할 수 없음을 의미하는 간단한 UI를 제공하는 것이었습니다(그러나 이것은 특정 복잡성 및 가파른 학습 곡선). 우리는 이 학습 곡선이 특히 취미 프로젝트의 경우 너무 많을 수 있다는 것을 알고 있으며 이를 개선하기 위해 노력하고 있습니다. 배포 등 구성을 더 쉽게 만들기 위해 올해 계획된 몇 가지 사항 ;)

https://appcenter.ms가 유망해 보입니다.

투명성의 이름으로 현재 우리가 있는 곳은 다음과 같습니다. Bitrise와 App Center CI 모두 GitHawk를 구축하고 있습니다. 두 서비스 모두 사용하기가 매우 쉽기 때문에 두 서비스를 모두 사용하여 여러 베타 빌드와 단일 App Store 빌드를 제공하고 내 프로세스를 문서화하려고 합니다.

여기 내 초기 생각이 있습니다

비트라이즈

장점

• 훌륭한 지원(h/t @viktorbenei)
• 꽤 빠른 빌드
• Fastlane을 통해 배포
• 빌드 단계의 극도의 사용자 정의 및 세분성
• 플랫폼은 오픈 소스(ish)입니다.
• master 에서 자동으로 빌드를 ITC로 푸시합니다(나는 이것을 _좋아합니다_).

단점

• 오픈 소스 무료 플랜 없음(_아직_)
• 시작(획득하거나 사라질 수 있음)

앱 센터

장점

• 빌드는 _매우_ 빠릅니다.
• 더 적은 사용자 정의 = 더 간소화
• iOS/Android 배포에 맞게 조정됨
• @TroubleMakerBen이 흔들린다 😄
• 마이크로소프트 지원
  
  
  
  • 아마 곧 사라지지 않을거야
  
  
  • ++리소스
  
  

단점

• 오픈 소스 무료 계획 없음(_아직_)
• 빌드하려면 공유 대상이 필요합니다.
• 자동화 배포 미정(도착 확인)
• 사용하지 않을 항목이 너무 많습니다(예: App Center SDK가 필요하지 않음).
• 로그 출력은 _매우 장황합니다_, 빌드 오류를 찾기 어렵습니다.
• GitHub 상태 통합 없음

@rnystrom 을 공유해 주셔서 감사합니다! 한 가지만 수정하면 bitrise의 웹 서비스 구성 요소는 오픈 소스가 아니므로 API 및 웹 UI를 자체 호스팅할 수 없습니다(아직 ;)). 구성을 실행하는 데 사용되는 모든 도구(워크플로 편집기, 러너 CLI 등)는 오픈 소스이므로 빌드 구성을 다운로드하여 자신의 Mac(또는 모든 Mac/Linux)에서 실행할 수 있습니다. 빠른 차선.

비교를 위해 질문 하나만

Bitrise: 단점: 오픈 소스 무료 계획 없음(아직)

AppCenter에 오픈 소스 계획이 있습니까? 그것을 놓쳤을 수도 있습니다. AFAIK 그들도 가지고 있지 않습니다. appcenter의 웹 사이트에서 관련 항목을 찾을 수 없어서 정말 궁금합니다.

GitHub 상태 통합 없음

크네요 ☹️

@viktorbenei 가 업데이트됩니다! 아직

_{GitHawk 와 함께}

안녕하세요 여러분,

피드백과 비교를 위한 Thx. 나는 그것을 좋아하고 우리 PM들이 이 스레드를 보고 있습니다.

자동화 배포 미정(도착 확인)

우리는 현재 더 나은 배포를 만들기 위해 열심히 노력하고 있습니다. 계속 지켜봐 주세요.

AppCenter에 오픈 소스 계획이 있습니까? 그것을 놓쳤을 수도 있습니다. AFAIK 그들도 가지고 있지 않습니다. appcenter의 웹 사이트에서 관련 항목을 찾을 수 없어서 정말 궁금합니다.

아직 OSS 계획이 없습니다.

모두 화이팅하시고 좋은 주말 보내세요!

이것은 지금 관련이 있을 수 있습니다 https://github.com/fastlane/ci 👍

@KrauseFx 나는 이것을 보았고 그것에 대해 너무

커뮤니티로서 기능을 구축할 수 있다면 왜 기능을 요청합니까? 게다가 구글이 이를 뒷받침하고 있다고요? 더 많은 것을 요구할 수 없었습니다.

코드가 진행됨에 따라 이에 기여하고 성숙해짐에 따라 워크플로에 적용할 수 있기를 진심으로 기대합니다.

커뮤니티를 위해 하는 모든 일에 감사드립니다!

@KrauseFx 플레이어 3이 게임에 입장했습니다

_{GitHawk 와 함께}

롤즈

앱 센터가 구문과 같은 [ci skip] 커밋당 지원하지 않는다고 생각합니다.

@dkhamsing은 불행히도 (아직) 아닙니다.

내가 사랑한 buddybuild의 진정한 장점 중 하나는 FBSnapshotTestCase 단위 테스트에서 예기치 않은 이미지가 생성된 경우 테스트 결과에서 전후/차이를 표시하는 방식이었습니다.

이러한 다른 시스템에 유사한 기능이 있는지 아는 사람이 있습니까?

App Center는 pull 요청에서 빌드를 지원합니까? 나는 매우 혼란스러워 cc @TroubleMakerBen

@dkhamsing 그렇군요 !

편집: 신경 쓰지 마세요 🙊

_{GitHawk 와 함께}

@dkhamsing App Center는 PUSH 기반 빌드를 지원하지만 아직 PR 기반 빌드(병합 기반 빌드)는 지원하지 않습니다.

아 알겠습니다. Thx Ryan, 벤 😊

_{GitHawk 와 함께}

이 스레드를 읽은 후에는 Bitrise와 App Center의 두 가지 경주인 것 같습니다. 그러나 아무도 UI 테스트 주제에 대해 언급하지 않았습니다. BB에서 몇 번의 클릭만으로 가상 장치에서 에스프레소 테스트를 실행할 수 있다는 점이 마음에 들었습니다. 논의 중인 두 플랫폼 중 어느 것이 이를 지원합니까?

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

_{GitHawk 와 함께}

@dkhamsing App Center Test는 실제로 물리적 장치에서 UI 테스트를 실행합니다. 수천 개가 있습니다. 아니요, 사진을 볼 수 없습니다 ;)

우리는 실제로 새로운 CI 솔루션을 식별하려고 노력하고 있습니다.

• AppCenter : bb와 유사하지만 PR 지원을 제공하지 않습니다. 관리 인력에 더 초점을 맞춘다고 생각합니다. 또한 작업이 실패하면 로그가 스택을 제공하지 않습니다.

• Bitrise: 매우 구성 가능하고 codecoverage, 배포, 서명, unitTest, UITest, 빌드, 전달, 정리 및 사용자 지정과 같은 많은 개방형 "단계"를 제공합니다. 구성할 수 있는 기능이 있기 때문에 .yaml 파일과 약간 혼동됩니다. 푸시, PR 등의 단계를 트리거할 수 있습니다.

• Nevercode 매우 구성 가능하며 분기별 gradlew 작업, PR 빌드, 무료 계획 없음 중에서 선택할 수 있습니다.

적어도 Bitrise 는 우리가 활용할 수 있는 많은 기능을 제공한다고 생각합니다!

App Center에서의 테스트에 대해 위에 게시된 링크에서

1. 핵심 개념 검토
   Test Cloud 경험의 핵심 개념을 이해하면 지원을 통해 사용, 탐색 및 커뮤니케이션이 용이해집니다. 첫 번째 테스트를 실행하기 전에 이러한 개념에 익숙해지는 것이 좋습니다.

도대체... 나는 핵심이든 아니든 어떤 개념도 검토하고 싶지 않습니다. BB에서 했던 것처럼 2번의 클릭으로 작동하기를 원합니다. 저는 데브옵스 엔지니어가 아니라 코더입니다...

예, App Center 문서를 간소화할 수 있습니다.

_{GitHawk 와 함께}

@acristescu

이 스레드를 읽은 후에는 Bitrise와 App Center의 두 가지 경주인 것 같습니다. 그러나 아무도 UI 테스트 주제에 대해 언급하지 않았습니다. BB에서 몇 번의 클릭만으로 가상 장치에서 에스프레소 테스트를 실행할 수 있다는 점이 마음에 들었습니다. 논의 중인 두 플랫폼 중 어느 것이 이를 지원합니까?

(아직) 한 번의 클릭은 아니지만 몇 가지 방법으로 더 강력합니다. https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

우리는 설정을 더 쉽게 만들기 위해 노력하고 있습니다(이것이 기능 부족 때문이 아니라 여전히 "베타"인 이유 ;)).

@acristescu @dkhamsing 우리는 알고 있습니다! 피드백을 계속하십시오.

@viktorbenei 시도할 예정이지만 맙소사 아트 스타일이

문제 없습니다 @acristescu , 나는 당신의 요점을 분명히 알고 있습니다. 정직한 피드백은 항상 환영하며 디자인 업데이트는 이미 작업 중입니다 ;)

나는 간단한 리포지토리( https://github.com/acristescu/GreenfieldTemplate )로 둘 다 시도하고 내가 어디로 가는지 보기로 결정했습니다. 지금까지 App Center를 시도하고 몇 가지 걸림돌이 발생했습니다.

• 해결되었습니다(gradle 빌드 도구를 찾을 수 없습니다!). google() 저장소를 프로젝트의 gradle에 수동으로 추가해야 합니다.
• 빌드 번호가 1에서 다시 시작되었지만 이미 Play 스토어에서 42를 출시했지만 Google은 빌드를 거부할 것입니다!)
• 가상 장치에서 무료로 테스트하는 방법을 찾을 수 없었고 30일 무료 평가판 이 있는 실제 장치에서만
• 단위 테스트를 실행했는지 확실하지 않습니다.

##[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.

그게 뭔지는 모르겠지만...

Bitrise: 플러스 측면에서 설정은 고통스럽지 않았지만 무엇이든 변경해야 하는 경우 yml 파일을 가져와서 조작해야 한다고 생각합니다(업데이트: 워크플로 편집기라는 것을 찾았습니다. 무섭지만 강력해 보입니다) . 걸림돌:

• 빌드할 변형을 묻지 않고 잘못된 변형을 선택했습니다. 나는 prodRelease 원했지만 어떤 이유로든 정확히 다른 두 개의 mockDebug 및 prodDebug 를 빌드하기로 결정했습니다. 어디에서 변경해야하는지 찾을 수 없지만 하나는 있어야한다고 확신합니다.
• 빌드는 앱 센터의 경우 2분 16분 대신 4분이 더 오래 걸렸습니다. 이것은 아마도 위의 문제 때문일까요?
• 로그 어디에도 junit 테스트에 대한 언급이 없습니다. 나는 그것이 그들을 실행했는지 의심합니다. 워크플로 편집기 어딘가에 추가하는 방법이 확실하지 않습니까? (업데이트가 약 10분 동안 워크플로 편집기를 수정하여 찾았습니다. 실행할 test 대상을 자유롭게 선택할 수 있는 보너스 포인트)
• 어떤 빌드 ID를 사용했는지 잘 모르겠는데 어떻게 보나요?

이것을 게시하기 위해 Thx

_{GitHawk 와 함께}

자세한 피드백을 보내 주신 @acristescu 에게 감사드립니다. 대단히 감사합니다. 특히 App Center의 JUnit 테스트 보고서 파일에 대한 경고에서 이는 실제 테스트 실행에 영향을 미치지 않으며 곧 수정되어야 합니다.
계속 오세요!

두 시간이 걸렸지만 앱 센터에서 Google Play에 업로드하도록 설득했습니다. 그러나 이를 자동으로 수행하도록 설득할 수 없는 것 같습니다. 앱 센터에서 서명된 APK를 다운로드한 다음 이를 다시 배포/저장 섹션(!)에 업로드하여 작동하도록 해야 했습니다. 엄청나게 복잡해 보이는데 내가 뭘 잘못하고 있는 거지?

추신: 부상에 대한 모욕을 더하기 위해 BuddyBuild는 처음에 비활성화하는 것을 잊었고 사람의 개입 없이 자동으로 작동하기 때문에 같은 시간에 여러 번 배포했습니다...

안녕하세요 @acristescu 입니다 .

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

빌드할 변형을 묻지 않고 잘못된 변형을 선택했습니다. 나는 prodRelease를 원했지만 어떤 이유로든 정확히 다른 두 개의 mockDebug 및 prodDebug를 빌드하기로 결정했습니다. 어디에서 변경해야하는지 찾을 수 없지만 하나는 있어야한다고 확신합니다.

실제로 현재 스캐너는 기본 워크플로에 대해 구성된 assembleDebug 와 함께 Gradle Runner 단계를 추가합니다. 우리는 이것이 충분히 간단하지 않을 수 있다는 것을 알고 있지만 간단히 말해서 prodRelease 를 빌드하려는 경우 gradle 작업은 assembleProdRelease 입니다. lint를 실행하려는 경우 gradle 작업은 lint 입니다. Gradle Runner 단계에서 이 모든 작업을 수행할 수 있습니다. 사실 Gradle은 여러 작업을 처리할 수 있으므로 lint 를 실행한 다음 assembleProdRelease 를 작업으로 지정할 수도 있습니다. lint assembleProdRelease 둘 다 할 것입니다.

우리는 더 구체적인 단계(예: gradle lint 작업을 실행하는 "Lint" 단계, 해당 작업을 "Gradle Runner" 단계) 😉

빌드는 앱 센터의 경우 2분 16분 대신 4분이 더 오래 걸렸습니다. 이것은 아마도 위의 문제 때문일까요?

실제로 assembleDebug 가 단일 "ProdRelease" 대신 2개의 개별 APK/변형을 귀하의 경우에 생성할 가능성이 높기 때문에 사실인 것 같습니다.

로그 어디에도 junit 테스트에 대한 언급이 없습니다. 나는 그것이 그들을 실행했는지 의심합니다.

테스트를 실행할 Gradle Runner 단계의 Gradle 작업 입력으로 test 를 지정하거나 기본적으로 해당 gradle 작업을 실행하도록 구성된 Gradle 단위 테스트 단계를 추가합니다.

어떤 빌드 ID를 사용했는지 잘 모르겠는데 어떻게 보나요?

빌드 번호를 bitrise.io 빌드 번호로 설정했는지 여부를 의미하는 경우 기본적으로 설정하지 않습니다. 예를 들어 Android versionCode 및 versionName 변경 단계를 추가하면 됩니다.

귀하의 피드백에 다시 한번 감사드립니다. 우리는 듣고 있으며 이미 설정 경험의 이러한 점을 개선할 예정입니다! ;)

멋진 토론입니다. Carthage를 지원하는 BuddyBuild 대안을 찾기가 어렵습니다.

Nevercode를 살펴보니 cocoapods만 지원합니다.

앱 센터가 카르타고를 지원한다고 생각합니다.

다른 사람이 있습니까?

@jamesone

가장 좋은 옵션은 Bitrise가 될 수 있다고 생각합니다. Bitrise는 파이프라인 bitbucket 과 같은 플랫폼을 제공하며 단계를 사용하여 필요에 따라 구성할 수도 있습니다.

사실 우리는 bb에서 bitrise로 옮겼고 Android와 iOS를 사용하고 있으며 모든 것이 완벽합니다!

멋진 @cbedoy buddybuild 가 모든 지점에 제공하는 설치 가능한 빌드에 대해 무엇을 했습니까? Bitrise에는 이에 대한 통합 또는 지원이 있습니까?

PR 또는 태그를 푸시하거나 생성할 때 워크플로 (많은 _단계_)를 트리거할 수 있습니다.

또한 지점별로 빌드를 예약할 수 있습니다.

다음을 확인해야 합니다.

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

bitrise가 작동하는 방식을 이해하면 필요한 것을 기반으로 워크플로를 생성할 수 있습니다. 즉, 누군가 PR을 생성하는 경우 unitTesting을 실행하는 워크플로를 원하거나 마스터에 태그가 지정되었을 때 .ipa를 빌드하고 생성하는 워크플로를 원합니다.

Bitrise는 unitTest, CodeCoverage 또는 보관 및 배포 실행을 위해 타사 _steps_를 선택할 수 있는 도커 이미지와 같습니다.

멋진 남자! 정말 흥미롭게 들립니다. 나는 그것을 조사할 것이다.