GitHub Actions로 Web, macOS, Windows 앱 한 번에 배포하기

GitHub Actions 통합 배포는 하나의 릴리즈 입력으로 web, mac, win 산출물을 만들고 배포하는 CI/CD 구조
공통 버전, 릴리즈 노트, 검증 결과를 공유하고 플랫폼별 서명/업로드만 분리하는 릴리즈 오케스트레이션 방식
스토어 심사와 직접 배포의 차이를 반영해 빌드, 업로드, 게시 승인을 나누는 멀티 채널 출시 설계

해당 개념이 필요한 이유

web, mac, win은 같은 제품 버전을 공유하지만 배포 산출물과 심사 절차가 다르다.
macOS는 직접 배포와 Mac App Store 제출의 인증서/업로드 방식이 다르다.
Windows는 직접 배포용 설치 파일과 Microsoft Store 제출용 패키지가 다르다.
GitHub Actions secret은 인증서, Apple 계정 키, Microsoft Partner Center 키, Firebase 서비스 계정처럼 소스에 커밋하면 안 되는 값을 주입하는 경계다.

AS-IS

flowchart TD
  A[로컬에서 버전 변경] --> B[로컬 web 배포]
  A --> C[로컬 mac 빌드]
  A --> D[로컬 win 빌드]
  C --> E[수동 업로드]
  D --> E
  B --> F[배포 결과 수동 확인]

TO-BE

flowchart TD
  A[package.json version + release-notes] --> B[GitHub Actions release workflow]
  B --> C[validate: 버전, 노트, secrets, 대상 repo 확인]
  C --> D[build-web: 정적 파일 생성]
  C --> E[build-mac: DMG/ZIP 또는 MAS 빌드]
  C --> F[build-win: NSIS 또는 MSIX/AppX 빌드]
  D --> G[publish-web: Hosting 배포]
  E --> H[publish-mac: GitHub Release 또는 App Store Connect 업로드]
  F --> I[publish-win: GitHub Release 또는 Partner Center 업로드]
  G --> J[릴리즈 요약, checksum, 태그, changelog]
  H --> J
  I --> J

핵심 설계: 공통 코어와 플랫폼 어댑터

릴리즈 자동화는 공통 코어와 플랫폼 어댑터를 분리한다.

package.json                         # version source of truth
package-lock.json                    # npm version으로 함께 갱신
release-notes/vX.Y.Z.md              # 사람용 변경사항
electron-builder.yml                 # 데스크톱 패키징 설정
firebase.json 또는 hosting config      # web hosting 설정
.github/workflows/release.yml        # 통합 오케스트레이션
store/mac/metadata/                  # Apple 제출 메타데이터
store/win/metadata/                  # Microsoft Store 제출 메타데이터

공통 코어는 버전, 릴리즈 노트, 테스트, checksum, GitHub Release 같은 공통 산출물을 다룬다. 플랫폼 어댑터는 macOS 서명/공증, Mac App Store 제출, Windows 서명, Microsoft Store 제출, web hosting 배포처럼 채널마다 달라지는 절차만 담당한다.

릴리즈 입력값

릴리즈의 기준값은 package.json의 version 하나로 둔다. 새 버전을 만들 때는 수동 편집보다 다음 명령을 사용한다.

npm version 1.2.3 --no-git-tag-version

이 명령은 package.json과 package-lock.json의 루트 버전을 같이 맞춘다. Actions에서는 node -p "require('./package.json').version"로 버전을 읽고 v1.2.3 태그, release-notes/v1.2.3.md, 산출물 이름, GitHub Release 제목에 같은 값을 사용한다.

릴리즈 PR에는 다음 파일이 함께 있어야 한다.

release-notes/v1.2.3.md

릴리즈 노트가 없거나 TODO만 있으면 release workflow를 막는다. 이 검증은 새 프로젝트에서도 반드시 두는 것이 좋다. 버전만 올라가고 사용자가 읽을 변경사항이 없는 배포는 추적과 롤백이 어렵다.

GitHub Actions 전체 흐름

권장 workflow는 긴 스크립트를 한 job에 몰아넣지 않고, 하나의 검증 job과 플랫폼별 build/publish job으로 나눈다.

flowchart TD
  A[workflow_dispatch 또는 release tag] --> B[validate]
  B --> C[공통 버전 확인]
  B --> D[release-notes 확인]
  B --> E[필수 secrets 존재 확인]
  E --> F[build-web]
  E --> G[build-mac-direct]
  E --> H[build-win-direct]
  E --> I[build-mac-store]
  E --> J[build-win-store]
  F --> K[publish-web]
  G --> L[publish-desktop-release]
  H --> L
  I --> M[upload-app-store-connect]
  J --> N[upload-partner-center]
  K --> O[summary, checksum, release notes]
  L --> O
  M --> O
  N --> O

workflow에 꼭 들어갈 핵심만 남기면 다음 정도다.

validate: package.json과 lockfile 버전 일치, release-notes/vX.Y.Z.md 존재, 배포 대상 branch/tag, 필요한 secrets 존재 확인
build-web: Linux runner에서 web 정적 번들 생성과 dist 검증
build-mac-direct: macOS runner에서 DMG/ZIP 생성, 서명, 공증, 검증
build-win-direct: Windows runner에서 NSIS EXE 생성, 서명, updater metadata 검증
build-mac-store: macOS runner에서 mas 대상 빌드와 App Store Connect 업로드
build-win-store: Windows runner에서 Store 제출용 패키지 생성과 Partner Center 업로드
publish: artifact 다운로드, checksum 생성, GitHub Release/CDN 배포, web live 배포, 스토어 업로드 결과 요약
publish-web: 자동으로 live 배포
publish-direct-desktop: DMG/EXE를 GitHub Release 또는 자체 CDN에 업로드
upload-mac-store: App Store Connect에 업로드하고 심사 제출 전 draft 유지
upload-win-store: Partner Center에 업로드하고 심사 제출 전 draft 유지

스토어는 심사와 메타데이터 상태가 있으므로 “빌드 성공”과 “스토어 게시 완료”를 같은 의미로 두면 안 된다.

web 배포 과정

web은 정적 산출물을 만든 뒤 hosting provider에 업로드한다. Firebase Hosting 기준 과정은 다음과 같다.

flowchart TD
  A[GitHub Actions ubuntu runner] --> B[npm ci]
  B --> C[lint, test]
  C --> D[npm run build]
  D --> E[dist/index.html, JS asset 검증]
  E --> F[Firebase Hosting 인증]
  F --> G[live channel 배포]
  G --> H[배포 URL 확인]

Firebase 배포는 GitHub runner가 사람 대신 Firebase 프로젝트에 쓰기 작업을 하는 구조다. 그래서 firebaseServiceAccount에 넣을 service account JSON이 필요하다. Firebase GitHub Action 문서는 firebase init hosting:github 또는 GCP Service Accounts에서 service account를 만들고, JSON key를 GitHub secret에 저장하는 방식을 안내한다.

값	저장 위치	필요한 단계	왜 필요한지	확인/발급 위치
`FIREBASE_SERVICE_ACCOUNT_<PROJECT_ID>`	Secret	Firebase Hosting 인증	GitHub Actions가 Firebase Hosting에 `dist`를 업로드할 권한	`firebase init hosting:github` 또는 Google Cloud Console, IAM & Admin, Service Accounts
`FIREBASE_PROJECT_ID`	Variable	배포 대상 선택	같은 workflow를 dev/prod 프로젝트에 재사용하기 위한 프로젝트 식별자. 단일 프로젝트면 workflow에 하드코딩 가능	Firebase Console Project settings 또는 `firebase projects:list`
`VITE_*` production 값	Variable 또는 Secret	`npm run build`	Vite가 build time에 클라이언트 설정을 번들에 넣기 위한 값	각 서비스 콘솔, 예: Supabase Project Settings, API
`PUBLIC_RELEASE_REPO`	Variable	릴리즈 링크 생성	데스크톱 업데이트 파일을 별도 public repo에 둘 때 대상 repo 식별	GitHub repo owner/name
`PUBLIC_RELEASE_TOKEN`	Secret	별도 repo release 생성	`GITHUB_TOKEN`이 다른 repo에 쓸 수 없을 때 release asset 업로드 권한	GitHub fine-grained personal access token

VITE_* 값은 브라우저 번들에 들어가므로 “비밀”로 설계하면 안 된다. Supabase anon key처럼 공개 클라이언트 키로 쓰는 값은 RLS와 도메인 정책으로 보호한다. 그래도 프로젝트별 운영값이므로 GitHub Variables나 environment-scoped Secrets에 두면 새 프로젝트 복제와 환경 분리가 쉽다.

mac 직접 배포: DMG/ZIP

macOS 직접 배포는 App Store를 거치지 않고 사용자가 DMG/ZIP을 내려받아 설치하는 흐름이다.

flowchart TD
  A[GitHub Actions macOS runner] --> B[npm ci, build, electron compile]
  B --> C[Developer ID Application 인증서 import]
  C --> D[electron-builder --mac dmg zip]
  D --> E[codesign 서명]
  E --> F[Apple notarization 제출]
  F --> G[notarization ticket staple]
  G --> H[codesign, spctl, stapler 검증]
  H --> I[GitHub Release 또는 CDN 업로드]

electron-builder 문서 기준으로 macOS 직접 배포용 dmg와 zip은 서명과 공증이 필요하다. macOS 10.15 이후에는 App Store 밖에서 배포하는 앱에 notarization이 필요하고, 공증되지 않은 앱은 Gatekeeper에서 차단될 수 있다. 따라서 mac 직접 배포 job은 “패키징”만으로 끝나면 안 되고 “서명, 공증, 검증”까지 포함해야 한다.

값	저장 위치	필요한 단계	왜 필요한지	확인/발급 위치
`MAC_CERT_P12_BASE64` 또는 `CSC_LINK`	Secret	codesign	Developer ID Application 인증서를 CI keychain에 import해야 앱을 개발자 신원으로 서명할 수 있음	Apple Developer, Certificates, Identifiers & Profiles, Certificates. Mac에서는 Keychain Access에서 `.p12` export 후 base64
`MAC_CERT_PASSWORD` 또는 `CSC_KEY_PASSWORD`	Secret	인증서 import	`.p12` 파일을 복호화하기 위한 비밀번호	`.p12` export 시 직접 지정한 비밀번호
`APPLE_API_KEY`	Secret	notarization 인증	Apple notary service에 제출할 때 JWT 인증에 사용할 private key	App Store Connect, Users and Access, Integrations, App Store Connect API
`APPLE_API_KEY_ID`	Secret	notarization 인증	어떤 API key로 JWT를 만들지 식별	App Store Connect API key 목록의 Key ID
`APPLE_API_ISSUER`	Secret	notarization 인증	API key가 속한 issuer/team 식별	App Store Connect API, Issuer ID
`APPLE_ID`	Secret	notarization 인증 대안	API key 방식 대신 Apple ID 방식으로 공증할 때 사용	Apple Developer 계정 로그인 email
`APPLE_APP_SPECIFIC_PASSWORD`	Secret	notarization 인증 대안	Apple ID 방식에서 일반 비밀번호 대신 쓰는 앱 전용 비밀번호	Apple Account, Sign-In and Security, App-Specific Passwords
`APPLE_TEAM_ID`	Secret	notarization 인증 대안	Apple ID가 여러 team에 속할 수 있어 공증 대상 team을 지정	Apple Developer, Membership details
`APPLE_BUNDLE_ID`	Variable	빌드 설정 검증	`electron-builder.yml`의 `appId`와 Apple Developer의 Bundle ID가 일치하는지 확인	Apple Developer, Identifiers

APPLE_API_KEY, APPLE_API_KEY_ID, APPLE_API_ISSUER 방식과 APPLE_ID, APPLE_APP_SPECIFIC_PASSWORD, APPLE_TEAM_ID 방식 중 하나만 선택한다. CI에서는 계정 비밀번호 계열 값을 덜 쓰는 API key 방식이 운영하기 쉽다.

mac App Store 배포

Mac App Store는 직접 배포용 DMG와 다른 트랙이다. electron-builder에서는 mas 또는 mas-dev target을 분리한다.

flowchart TD
  A[GitHub Actions macOS runner] --> B[npm ci, build, electron compile]
  B --> C[Mac App Store용 인증서 import]
  C --> D[provisioning profile 복원]
  D --> E[electron-builder --mac mas]
  E --> F[App Store Connect 업로드]
  F --> G[Apple build processing]
  G --> H[TestFlight 또는 심사 제출 대기]

Mac App Store는 Apple이 제출 후 Store 배포 서명과 처리를 담당하므로 직접 배포처럼 Developer ID notarization을 붙이는 흐름이 아니다. 대신 mas target에 맞는 Apple Distribution 또는 Mac App Distribution 인증서, provisioning profile, App Store Connect 업로드 인증이 필요하다. Apple 문서에 따르면 빌드 업로드는 Xcode, altool, Transporter, App Store Connect API로 할 수 있고, bundle ID와 version number로 App Store Connect의 앱/버전과 연결된다.

값	저장 위치	필요한 단계	왜 필요한지	확인/발급 위치
`MAC_APP_STORE_CERT_P12_BASE64`	Secret	`mas` signing	App Store 제출용 앱 번들을 Apple 배포 인증서로 서명	Apple Developer, Certificates, Identifiers & Profiles, Certificates
`MAC_APP_STORE_CERT_PASSWORD`	Secret	인증서 import	`.p12` 인증서 복호화	`.p12` export 시 직접 지정한 비밀번호
`MAC_PROVISIONING_PROFILE_BASE64`	Secret	`mas` signing	Bundle ID, App Sandbox, entitlements, team 정보를 제출용 앱과 연결	Apple Developer, Profiles
`APP_STORE_CONNECT_API_KEY`	Secret	build upload	Transporter 또는 App Store Connect API가 JWT를 만들기 위한 private key	App Store Connect, Users and Access, Integrations, App Store Connect API
`APP_STORE_CONNECT_KEY_ID`	Secret	build upload	업로드에 사용할 API key 식별	App Store Connect API key 목록의 Key ID
`APP_STORE_CONNECT_ISSUER_ID`	Secret	build upload	API issuer/team 식별	App Store Connect API, Issuer ID
`APPLE_APP_ID`	Variable	upload 대상 확인	업로드된 build가 어느 App Store Connect 앱에 붙는지 확인	App Store Connect 앱 페이지 또는 API
`APPLE_BUNDLE_ID`	Variable	bundle 연결	앱 번들의 bundle ID가 App Store Connect 앱과 일치해야 함	Apple Developer Identifiers, App Store Connect App Information

App Store Connect는 빌드 업로드와 심사를 분리한다. CI가 할 일은 .pkg 또는 제출 가능한 앱 산출물을 만들고 Transporter/API로 업로드하는 것이다. 첫 앱 생성, 계약, 세금/은행 정보, 일부 메타데이터, 심사 질문은 사람 또는 별도 운영 절차가 먼저 처리해야 한다.

Windows 직접 배포: NSIS EXE

Windows 직접 배포는 NSIS 설치 파일을 만들고 GitHub Release 또는 자체 다운로드 서버에 올리는 흐름이다.

flowchart TD
  A[GitHub Actions Windows runner] --> B[npm ci, build, electron compile]
  B --> C[Windows code signing 인증서 주입]
  C --> D[electron-builder --win nsis]
  D --> E[EXE 서명]
  E --> F[latest.yml, blockmap 검증]
  F --> G[GitHub Release 또는 CDN 업로드]

Windows 직접 배포는 macOS처럼 notarization은 없지만, 서명이 없으면 사용자가 “Unknown publisher”나 SmartScreen 경고를 보게 된다. electron-builder는 Windows signing credential을 WIN_CSC_LINK, WIN_CSC_KEY_PASSWORD로 읽을 수 있다. 서명을 강제하고 싶으면 forceCodeSigning: true를 둬서 CI가 조용히 unsigned 산출물을 내지 못하게 한다.

값	저장 위치	필요한 단계	왜 필요한지	확인/발급 위치
`WIN_CSC_LINK`	Secret	Authenticode signing	Windows 설치 파일과 실행 파일을 게시자 신원으로 서명	OV/EV code signing certificate 발급 CA 또는 Azure Trusted Signing
`WIN_CSC_KEY_PASSWORD`	Secret	인증서 import	`.pfx` 인증서 복호화	`.pfx` export 시 지정한 비밀번호
`AZURE_TENANT_ID`	Secret	Azure Trusted Signing 대안	Azure Trusted Signing을 쓸 때 Entra tenant 식별	Azure Portal, Microsoft Entra ID
`AZURE_CLIENT_ID`	Secret	Azure Trusted Signing 대안	signing 요청을 수행할 app registration 식별	Azure Portal, App registrations
`AZURE_CLIENT_SECRET`	Secret	Azure Trusted Signing 대안	signing 요청 인증	Azure Portal, App registrations, Certificates & secrets
`WINDOWS_PUBLISHER_NAME`	Variable	updater 검증	electron-updater나 설치 검증에서 기대하는 publisher 이름을 명시	인증서 subject 또는 Partner Center product identity

서명이 없으면 설치 파일은 만들어질 수 있지만 SmartScreen 경고가 뜬다. 정식 배포는 OV/EV 인증서 또는 Azure Trusted Signing을 붙이는 방향이 좋다.

Microsoft Store 배포

Microsoft Store 제출은 직접 배포용 NSIS와 다른 트랙이다. electron-builder는 appx target을 지원하고, Store 제출은 Partner Center에서 제품을 만든 뒤 submission을 업로드하는 구조다.

flowchart TD
  A[Partner Center에서 앱 이름 예약]
  A --> B[Product identity 확인]
  B --> C[electron-builder appx 또는 msix 설정]
  C --> D[GitHub Actions Windows runner]
  D --> E[Store 제출용 package 생성]
  E --> F[Partner Center API access token 발급]
  F --> G[package, listing metadata 업로드]
  G --> H[submission draft 생성]
  H --> I[certification 제출 또는 수동 확인]

Microsoft Store 자동화는 “패키지 생성”과 “Partner Center submission 생성”이 분리된다. Microsoft 문서 기준으로 Store Submission API는 Microsoft Entra ID access token으로 호출하고, Partner Center 계정과 Entra ID application을 연결해야 한다. 또한 앱이 Partner Center에 없으면 API로 처음 만들 수 없으므로, 이름 예약과 최초 submission 준비는 먼저 수동으로 처리해야 한다.

값	저장 위치	필요한 단계	왜 필요한지	확인/발급 위치
`MICROSOFT_TENANT_ID`	Secret	access token 발급	Store Submission API token endpoint에 tenant id가 필요	Partner Center에 연결된 Microsoft Entra ID
`MICROSOFT_CLIENT_ID`	Secret	access token 발급	Partner Center에 Manager role로 연결된 Entra application 식별	Partner Center Account settings, Users 또는 Azure Portal App registrations
`MICROSOFT_CLIENT_SECRET`	Secret	access token 발급	client credentials flow에서 access token 발급	Azure Portal, App registrations, Certificates & secrets
`MICROSOFT_SELLER_ID`	Secret 또는 Variable	API header	Store Submission API의 `X-Seller-Account-Id` header에 필요	Partner Center account settings
`MICROSOFT_STORE_PRODUCT_ID`	Variable	submission API path	`/submission/v1/product/{productId}` 호출 대상	Partner Center 제품 페이지 또는 Store API
`APPX_IDENTITY_NAME`	Variable	package identity 검증	`electron-builder.yml`의 `appx.identityName`이 Partner Center product identity와 일치해야 함	Partner Center, Product identity
`APPX_PUBLISHER`	Variable	package identity 검증	`appx.publisher` 값이 Partner Center가 요구하는 publisher subject와 일치해야 함	Partner Center, Product identity
`MICROSOFT_STORE_PACKAGE_FLIGHT`	Variable	flight 배포	production이 아닌 flight/ring에 올릴 때 대상 구분	Partner Center flight 설정

Store 제출용 package는 .appx, .msix, .appxupload, .msixupload 중 프로젝트 도구와 제출 방식에 맞는 형식을 선택한다. Microsoft 문서는 Store 제출용으로 upload package를 권장한다. Electron 프로젝트에서 appx target을 쓸 때는 Windows runner에서 빌드하는 것을 기본으로 둔다.

GitHub Secrets와 Variables 설계

secret과 variable을 구분한다.

Secret: 인증서, private key, client secret, service account JSON, token
Variable: project id, bundle id, product id, public release repo, channel name

권장 environment는 다음과 같다.

GitHub Environments
  production
    secrets:
      FIREBASE_SERVICE_ACCOUNT_<PROJECT_ID>
      MAC_CERT_P12_BASE64
      MAC_CERT_PASSWORD
      APPLE_ID
      APPLE_APP_SPECIFIC_PASSWORD
      APPLE_TEAM_ID
      WIN_CSC_LINK
      WIN_CSC_KEY_PASSWORD
      PUBLIC_RELEASE_TOKEN
      MICROSOFT_TENANT_ID
      MICROSOFT_CLIENT_ID
      MICROSOFT_CLIENT_SECRET
      MICROSOFT_SELLER_ID
      APP_STORE_CONNECT_API_KEY
      APP_STORE_CONNECT_KEY_ID
      APP_STORE_CONNECT_ISSUER_ID
    variables:
      FIREBASE_PROJECT_ID
      PUBLIC_RELEASE_REPO
      APPLE_BUNDLE_ID
      APPLE_APP_ID
      MICROSOFT_STORE_PRODUCT_ID
      APPX_IDENTITY_NAME
      APPX_PUBLISHER

GitHub Actions secret 이름은 영문자, 숫자, underscore만 사용하고 GITHUB_로 시작하지 않는다. production environment에 승인자를 두면 실수로 정식 배포가 실행되는 일을 줄일 수 있다.

값 준비와 검증 방법

Apple 인증서는 Apple Developer에서 만든 뒤 Mac Keychain에 설치하고 .p12로 export한다. CI secret에는 원본 파일을 넣지 않고 base64 문자열을 넣는다.

base64 -i certificate.p12 | pbcopy

Windows 인증서는 .pfx를 base64로 변환한다.

certutil -encode certificate.pfx certificate.pfx.base64

CI에서는 secret 값이 비어 있는지 먼저 검사한다. macOS direct 배포라면 build 전에 MAC_CERT_P12_BASE64, MAC_CERT_PASSWORD, notarization 인증값 중 한 세트가 모두 있는지 확인한다. Microsoft Store 배포라면 token 발급에 필요한 MICROSOFT_TENANT_ID, MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET과 API header/path에 필요한 MICROSOFT_SELLER_ID, MICROSOFT_STORE_PRODUCT_ID를 먼저 확인한다.

Firebase service account JSON, App Store Connect API private key, Microsoft client secret은 로그에 출력하지 않는다. App Store Connect API key는 한 번만 다운로드할 수 있고, Microsoft client secret은 만료일이 있으므로 password manager와 운영 캘린더에 같이 기록한다.

새 프로젝트 체크리스트

package.json에 name, productName, version, main을 정한다.
electron-builder.yml에 appId, productName, mac, win, appx, files, extraResources를 정한다.
release-notes/README.md와 release-notes/vX.Y.Z.md 규칙을 만든다.
scripts/validate-release-metadata.mjs로 version, lockfile, release notes를 검증한다.
npm run lint, npm test -- --run, npm run build, npm run electron:compile을 release workflow에 넣는다.
macOS 직접 배포는 macos-14 runner에서 서명, 공증, spctl, stapler 검증까지 수행한다.
Windows 직접 배포는 windows-2022 runner에서 NSIS 빌드와 updater metadata 검증을 수행한다.
web은 ubuntu-latest runner에서 dist를 만들고 Hosting에 배포한다.
모든 산출물에 checksum을 만들고 GitHub Release 또는 별도 public release repo에 업로드한다.
Store 제출은 별도 job으로 분리하고, review 제출 직전에는 GitHub environment approval을 둔다.

beBetter repo에서 이미 적용된 패턴

현재 repo는 다음 패턴을 이미 갖고 있다.

package.json의 version을 공통 릴리즈 버전으로 사용
release-notes/vX.Y.Z.md를 요구하는 검증 스크립트
release-desktop.yml에서 validate, build-macos, build-windows, build-web, publish job 분리
macOS dmg/zip, Windows nsis, web dist를 각각 artifact로 보존
publish job에서 checksum 생성, public release repo에 metadata commit, draft GitHub Release 생성, Firebase Hosting 배포, release publish 순서 적용

이 구조를 새 프로젝트에 옮길 때 프로젝트명, app id, Firebase project id, public release repo, Apple team, Microsoft Store product id만 바꾸면 된다.

주의할 경계

스토어 자동화는 “파일 업로드”와 “사용자에게 공개”가 다르다. Apple과 Microsoft 모두 심사/처리 상태가 있고, 첫 앱 생성과 일부 계정 설정은 수동 작업이 선행된다. 따라서 통합 workflow의 완료 조건은 채널별로 다르게 잡는다.

web: live URL에 새 bundle이 올라가면 완료
mac direct: signed/notarized DMG/ZIP이 GitHub Release 또는 CDN에 올라가면 완료
win direct: signed EXE와 updater metadata가 GitHub Release 또는 CDN에 올라가면 완료
mac App Store: App Store Connect에 build가 처리되어 심사 가능한 상태면 CI 완료
Microsoft Store: Partner Center submission draft 또는 제출 상태가 생성되면 CI 완료

Explorer

날짜별 보기

2026년 (154)

2025년 (9)