본 게시글은 이전 게시글에서 이어서 작성된 부분입니다.
2022.03.30 - [Android/CI CD] - [Bitrise] Bitrise를 사용해보자 - 1. 기본 Setting
2022.04.01 - [Android/CI CD] - [Bitrise] Bitrise를 사용해보자 - 2. Slack 연동
2022.04.06 - [Android/CI CD] - [Bitrise] Bitrise를 사용해보자 - 3. Unit Test
실제로 사용하는게 아니라 테스트를 위해서 작업해서 그런지는 모르겠지만,
Bitrsize에서 적용하면 좋을 것 같아 보이는 기능을 찾아 추가해보려 기능을 찾아보아도 사이닝을 하고 앱을 스토어에 배포하는 것 외에는 추가할만한게 눈에 띄지 않았다.
따라서, Trigger를 사용하여 빌드에 조건을 몇가지 걸어보도록 하자.
우선,
Triggers 탭에서 추가할 수 있는 트리거는 Push, Pull Request, Tag 3개가 존재한다.
그 중, 이전에 추가했었던 Push에 대한 조건을 하나 더 추가해보자.
현재 Main Branch밖에 없으므로 develop브랜치를 생성하여 정상 동작하는지 테스트를 해보도록 하자.
그 전에 기존에 사용하던 workflow는 테스트까지 들어가 있으므로, workflow를 추가해주도록 하자.
Workflow에서 +버튼을 눌러서 생성하면 되는데,
생성할 때 Base가 되는 workflow를 지정할 수 있다.
Base가 된다는게 무슨 의미인가 했는데, 결국은 해당 workflow를 복사해서 새로운 workflow를 만들어 준다는 것이다.
빈 workflow를 추가해서 하나하나 다시 추가하기는 귀찮으니, primary로 생성한 뒤에 필요하지 않은 부분을 제거해서 workflow를 새로 만들어 주었다.
새로 만든 workflow로 설정해서 저장해 준다.
하나만 작업하고 테스트하기에는 아까우니, Tag에 대한 Trigger도 추가해준다.
위와 동일한 방식으로 workflow를 생성하고 build라는 tag에 대하여 동작할 수 있게 설정한다.
그 후, 각각 push하여 결과를 확인한다.
필자는 테스트를 위하여 develop 브랜치에 push와 tag push를 각각 진행해보고, 한번에 진행해보았는데 결과는 동일하다.
한번에 진행했을 때도 위의 사진처럼 2개의 Build가 생성되고, 순차적으로 하나씩 빌드가 진행되게 된다.
순차적으로 진행되는 이유는 무료 버전을 사용하고 있기 때문이고, 유료버전을 사용하게 되면 동시에 진행될 것이다.
그런데 생각을 해보면
브랜치야 고정된 브랜치로 push할 경우를 트리거로 사용하여 빌드를 해도 되지만, Tag의 경우에는 동일한 태그로 push하는 것이 아닌 상황에 따라 일정 규칙에 맞춰서 Tag를 붙여서 push한다.
하지만 현재 설정한 것을 확인해보면, build라는 태그일 경우에만 트리거에 걸리게 되는데 이것은 실제로 사용할 때 많이 사용되지 않을 것으로 보인다.
따라서,
WildCard를 사용하여 Tag에 대한 트리거를 만들어 보도록 하자.
해당 설명을 확인하기 위하여 Bitrise Docs에서 트리거에 대한 설명을 확인해보자.
그냥 확인해보니 *를 붙이기만 하면 되는 것으로 보인다.
예시로는 suffix에 dev를 붙였으므로, prefix에 dev를 붙여서 테스트해보도록 하자.
devTest라는 Tag를 커밋하였는데 정상적으로 동작하였다.
필자는 보통 Tag를 사용할 때는 앱 배포가 진행된 부분에 release_v.~ 와 같이 버전으로 태그를 달거나 특정한 경우에만 특정 규칙을 사용하여 태그를 달아두었다.
따라서, 태그를 트리거로 사용하기 위해서는 이처럼 wildCard를 사용하여 특정 규칙에 맞도록 작성을 해서 사용하는 것이 높은 효율을 보일 수 있을 것이다.
*
추후 Bitrise Docs를 확인해보니 다음과 같은 name, file path 규칙을 찾을 수 있었다.
다음으로는
PR 트리거를 사용해보자.
위에서 develop 브랜치를 만들었으므로, PR을 통해 Main 브랜치로 merge를 진행해보도록 하자.
workflow 또한 해당 트리거를 위해 새롭게 만들어서 적용해 두었다.
Github를 사용하고 있으므로, PR 생성을 하면 이처럼 Github에서 확인이 가능하다.
PR을 승인하게 되면 위의 사진처럼 Merge작업이 된 것을 확인할 수 있다.
그렇다면 이제 Bitrise에 들어가서 PR에 대한 빌드가 정상적으로 진행되는지 확인해보자.
PR을 통해 Main으로 Merge작업이 진행되므로,
- develop 브랜치로 push
- PR요청에 따른 develop 브랜치를 main 브랜치로 merge
- merge가 성공적으로 되었으므로, main 브랜치로 push
작업이 순서대로 진행되는 것이다.
따라서 위와 같이 3개의 빌드가 진행되게 된다.
여기서,
1번의 경우 merge Test라는 메세지가 나오고, 2번의 경우 뒤에 check가 붙은 것을 볼 수 있다.
여기서 check는 PR 요청 시 github에서 붙였던 텍스트로 해당 메세지가 이처럼 붙여서 보이게 되는 것이다.
또한, merge작업이 진행되기 떄문에 왼편에 보이는 아이콘이 머지를 표시하는 아이콘으로 변경 된 것을 볼 수 있다.
생각해보면,
보통 Push나 PR 뿐 아니라 시간에 따른 트리거도 자주 사용하는데, Bitrise의 Triggers 탭에서는 확인 할 수 없다.
그렇다면 어디서 Schedule에 대한 트리거 설정을 해주는가 찾아보면,
Build 탭의 가장 오른편을 보면 찾을 수 있다.
Start/Schedule a Build를 누르면 다음과 같은 화면이 나오는데, 기본적인 설정은 basic을 통해서 간단하게 설정이 가능하다.
화면을 확인해보면 Schedule this build Bata 부분이 활성화가 되어있지 않다.
따라서, 해당 부분을 활성화를 해주면 Schedule에 대한 옵션들이 나오게 된다.
빌드가 진행될 시간과 요일을 설정할 수 있다.
별도로 코드로 작성하는게 아닌, 요일은 클릭하여 on/off 할 수 있고, 시간은 간단하게 입력하여 설정이 가능하다.
그것 외에도 빌드를 진행할 브랜치와 workflow, 빌드 시 확인 할 메세지를 입력하고 Schedule Build를 눌러서 저장만 시켜주면 된다.
정상적으로 적용이 되면 위의 사진처럼 확인이 가능하다.
해당 작업이 정상적으로 진행될를 마냥 기다릴 수 없으므로 시간을 조절해서 확인해보도록 하자.
정상적으로 되는 것을 확인 할 수 있다.
위의 이미지에서 Running 중인 항목을 보면 알 수 있겠지만, workflow와 빌드 메세지를 제외하고는 다른 빌드와 구분할 수 있는 항목이 없는 것으로 보인다.
따라서, 스케쥴러를 사용하여 주기적인 빌드를 진행할 때는 별도의 workflow를 작성해서 사용하거나, 빌드 시 나오는 메세지를 구분할 수 있도록 작성해서 사용해야할 것으로 보인다.
이것으로 간단하게 Bitrise Trigger에 대한 설정을 해보았다.
트리거에 대한 설정은 Github Actions에서도 아주 간단한 코드로 설정할 수 있었는데,
아무래도 Bitrise는 코드작성이 아니기 때문에 조금 더 쉽고, 간단하게 적용되는 것으로 느껴진다.
지금은 간단하게 추가가 가능한 4가지 종류의 트리거를 하나씩 추가해 보았는데, 상황에 따라서 다양하게 트리거를 작성해 둔다면 조금 더 편리하고, 휴먼 에러를 발생시키지 않고 많은 작업들을 진행할 수 있을 것으로 보인다.
'Android > CI CD' 카테고리의 다른 글
| [Bitrise] Bitrise를 사용해보자 - 3. Unit Test (0) | 2022.05.11 |
|---|---|
| [Github Actions] Github Actions를 사용해보자 - 5. 추가 기능 (0) | 2022.04.05 |
| [Bitrise] Bitrise를 사용해보자 - 2. Slack 연동 (0) | 2022.04.01 |
| [Bitrise] Bitrise를 사용해보자 - 1. 기본 Setting (0) | 2022.03.30 |
| [Github Actions] Github Actions를 사용해보자 - 4. Slack 연동 (0) | 2022.03.28 |
