사전에 명시된 권한
토큰을 생성하기 전에 토큰이 수행할 수 있어야 하는 작업과 그 이유를 알려드립니다. 요청하기가 더 쉬웠다는 이유만으로 포괄적인 범위를 지정하지 않으며, 작업에 필요한 것보다 더 많은 것을 원했음을 사후에 발견하는 일도 없습니다.
소스 제어
이미 사용 중인 리포지토리에서 배포하세요 — 배치할 수 있는 9곳의 위치
작업 중인 GitHub 또는 GitLab 계정을 연결하고 브랜치에서 직접 배포하세요. Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps, AWS Amplify는 물론, 저장소와 사이트 파일이 양방향으로 동기화 상태를 유지하는 당사의 매니지드 호스팅에도 배포할 수 있습니다. 모든 연결은 필요한 권한을 표시하고, 저장되기 전에 제공업체의 API를 통해 검증되며, Vault에 보관됩니다. GitHub 또는 GitLab을 사용해 로그인하실 수도 있습니다.
- GitHub + GitLab이미 보유하고 계신 계정을 연결하세요
- 9개 대상8개의 엣지 호스트와 당사 자체 플릿
- 양방향 동기화모든 사이트, 모든 라인
- Vault에 저장됨입력 시 유효성 검사됨, 로그에는 절대 기록되지 않음
- 토큰이 저장되기 전에 확인되었습니다범위가 지나치게 넓은 토큰은 결코 반영되지 않습니다
- 푸시하여 배포서명 확인됨, 선택 사항
- 귀하의 브랜치, 귀하의 빌드디렉터리를 게시하거나 자체 CI를 실행하세요
- 안전하게 연결 끊기저희가 만든 후크를 정확히 제거합니다
한 번 연결하고 어떤 내용에 동의하는지 확인해 보세요
연결은 다른 사람에게 전달하는 자격 증명입니다. 당사의 연결은 생성하기 전에 필요한 항목을 명시하고, 저장하기 전에 정상 작동 여부를 입증하며, 양쪽 어디에서든 취소할 수 있습니다.
제공업체를 통해 확인되었으며, 단순한 신뢰만으로 수락되지 않았습니다
토큰을 저장하기 전에 해당 토큰으로 공급자의 자체 API를 호출합니다. 잘못되었거나 만료되었거나 범위가 잘못 지정된 토큰은 정상으로 표시되며 승인된 후 첫 실제 배포에서 실패하는 대신 양식 단계에서 거부됩니다.
Vault에 저장되며 다른 곳에는 저장되지 않습니다
저희 코드에도, 환경 파일에도, 로그에도, 명령줄에도 없습니다. 그것을 사용하는 워크로드에 의해, 사용되는 바로 그 순간에 확인됩니다.
사이트별로 선택된 하나 이상의 계정
개인 계정과 조직 계정을 연결하거나, 두 조직 계정을 연결하세요. 각 사이트는 배포할 계정을 선택하므로 클라이언트의 리포지토리와 본인의 리포지토리가 자격 증명을 공유하지 않습니다.
리포지토리가 도달할 수 있는 9가지 위치
8개의 관리형 에지 호스트와 당사 자체 플릿. 대상은 연결이 아닌 사이트의 속성이므로 동일한 리포지토리가 한 브랜치를 Pages 호스트에 게시하고 다른 사이트를 당사 하드웨어에서 실행할 수 있습니다.
Cloudflare Pages
무제한 대역폭, 상업적 이용 허용, 일반적으로 귀하의 DNS 영역을 호스팅하는 동일한 공급자에서 처리되는 apex 도메인. 이러한 이유로 저희가 가장 먼저 선택하는 목적지입니다.
Cloudflare Pages 호스팅 →GitHub Pages
코드가 이미 있는 리포지토리에서 직접 게시하세요. 공유 github.io 인프라 자체가 풋프린트이므로 Footprint-Free 줄에 표시되었습니다.
GitHub Pages 호스팅 →GitLab Pages, Netlify, Vercel 및 기타
GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps 및 AWS Amplify는 모두 동일한 연결과 동일한 배포 기록을 사용하여 사이트가 가리키도록 설정할 수 있는 대상입니다.
정적 사이트 호스팅 →자체 매니지드 호스팅
빌드된 번들이 아닌 완전한 애플리케이션 — WordPress, PHP, Node. 양방향 동기화가 적용되는 대상이므로 서버와 브랜치의 파일이 일치된 상태로 유지됩니다.
매니지드 호스팅 →타인의 엣지에 있는 사이트
당사 소유가 아닌 호스트에 게시된 사이트도 사용량을 소모하며, 배포 내역, 가동 시간 및 SEO 데이터와 함께 실행 중인 다른 모든 항목과 나란히 대시보드에 표시됩니다.
외부 사이트 허용량 →또는 여기에서 편집하십시오
브라우저 내 편집기는 양방향 동기화가 다시 푸시하는 동일한 파일에서 작동하므로, 대시보드에서의 빠른 수정이 나중에 아무도 찾을 수 없는 변경 사항이 되는 대신 귀하의 브랜치에 커밋으로 반영됩니다.
웹 편집기 →양방향 동기화
저장소와 라이브 사이트의 완벽한 조화
이 기능을 켜면 사이트 자체의 파일이 사용자의 branch로 다시 커밋되고, 해당 branch의 커밋은 다시 사이트로 내려옵니다. 당사에서 호스팅하는 모든 사이트, 모든 라인에서 작동합니다. 유일한 요구 사항은 기본 머신이 해당 파일에 대해 Git을 실행할 수 있어야 한다는 점이며, 이는 플랜에서 추정하는 것이 아니라 서버에 직접 요청하여 확인합니다.
동기화할 디렉터리는 귀하께서 직접 선택하실 수 있습니다. WordPress 고객은 4만 개의 코어 파일이 아닌 자신의 테마가 추적되기를 원하기 때문입니다. 그리고 직접 켜기 전까지는 비활성화 상태로 유지됩니다. 동기화를 활성화하는 것은 타인의 저장소에 관한 결정이므로, 마이그레이션이 이를 대신 결정해서는 안 됩니다.
- 당사 하드웨어에서의 편집은 귀하의 브랜치에 커밋으로 반영됩니다
- 브랜치의 커밋이 사이트에 다시 반영됩니다
- 전체 문서 루트가 아닌 단일 디렉터리(테마, 플러그인 등)만 동기화합니다
- 기존의 모든 사이트를 포함하여 기본적으로 꺼져 있음
디렉터리를 게시하거나 자체 CI가 빌드하도록 하세요
두 가지 모드가 있으며, 차이점은 빌드가 실행되는 위치입니다. 둘 다 동일한 위치에서 끝납니다. 바로 당사가 가져와 게시하는 참조이며, 커밋은 배포에 맞춰 기록됩니다.
- 게시 모드는 브랜치를 있는 그대로 가져와 지정한 디렉터리를 게시합니다. 비워 두면 리포지토리 루트를 의미합니다.
- CI 모드는 제공업체의 자체 파이프라인에서 빌드 명령을 실행하고 출력을 별도의 게시 브랜치에 커밋하며, 당사는 이를 다른 참조와 마찬가지로 가져옵니다.
- 배포가 게시되는 브랜치는 항상 명시적인 이름으로 지정되며, 결코 '기본 브랜치'로 표시되지 않습니다. 기본 설정은 사용자가 모르는 사이에 변경될 수 있으며, 어떤 브랜치를 게시했는지 알 수 없는 이력은 제대로 된 이력이라고 할 수 없습니다.
- 자동 배포는 기본적으로 활성화되어 있으며 웹훅을 제거하지 않고도 끌 수 있으므로, 실행을 허용하기 전에 전송 내용의 도착 여부를 확인할 수 있습니다.
- 모든 배포는 커밋, 결과 및 시간을 기록하고 백그라운드에서 실행되며, 빌드가 완료되면 페이지가 업데이트됩니다.
- 연결을 해제하면 당사가 생성한 웹훅만 해당 id를 통해 정확히 삭제되며, 저장소의 다른 항목은 일절 삭제되지 않습니다.
리포지토리에서 라이브 사이트까지
계정 연결
연결 아래의 GitHub 또는 GitLab. 권한은 토큰을 생성하기 전에 나열되며, 저장되기 전에 공급자를 대상으로 확인됩니다.
사이트를 리포지토리로 연결하기
소유자, 저장소, 브랜치, 그리고 디렉터리를 게시할지 아니면 귀하의 CI가 빌드한 항목을 가져올지 여부입니다. 그 일환으로 푸시 웹훅을 등록합니다.
밀거나 버튼을 누르세요
지정된 브랜치로 푸시하면 배포가 시작되며, 또는 사이트의 배포 탭에서 요청 시 배포할 수도 있습니다. 빌드는 백그라운드에서 실행됩니다.
시청하시고, 원하시면 다시 동기화하세요
배포 내역은 무엇이 언제 게시되었는지 보여줍니다. 양방향 동기화를 켜면 여기서 수정한 내용이 브랜치에 커밋으로 반영됩니다.
문제가 발생한 경우
'연결되었지만 전달되지 않음'은 저희가 실제로 알려드리는 상태입니다
정상적으로 보이지만 아무것도 수신하지 않는 리포지토리 연결은 전형적인 무음 오류입니다. 잘못된 범위의 토큰, 공급자 측에서 차단된 전송, 누군가 수동으로 제거한 훅 등이 원인일 수 있습니다. 다른 모든 화면에서는 보이지 않으므로 리포지토리 카드에 직접 표시됩니다. 공급자가 마지막으로 전송한 시점과 그 응답 내용이 여기에 해당합니다.
전달 건은 조치를 취하기 전에 각 공급자의 고유 체계를 사용하여 서명을 확인하며, 모든 공급자에게 적용된다고 가정한 체계를 사용하지 않습니다. 확인되지 않은 전달 건은 조용히 무시되지 않고 거부되어 기록됩니다.
- 카드의 마지막 전송 시간 및 메시지
- 비워 두지 않고 '배달되지 않음'으로 표시됩니다
- 작업이 실행되기 전에 공급자별로 서명이 확인되었습니다
- 연결을 끊으면 생성된 후크가 ID에 따라 제거됩니다
ID
GitHub 또는 GitLab으로 로그인 — 또는 Google, 또는 Microsoft
이메일 주소 및 비밀번호와 함께 GitHub, GitLab, Google 또는 Microsoft를 사용하여 Zinn Digital® 계정에 로그인할 수 있습니다. ID 레이어가 핸드셰이크를 처리하므로 당사는 제공업체 비밀번호를 절대 보지 못하며, 소셜 계정을 기존 Zinn® 계정에 연결할 때도 여전히 이메일을 통한 확인이 필요합니다.
GitHub로 로그인하는 것과 배포를 위해 GitHub를 연결하는 것은 별개의 결정이며 별개의 자격 증명입니다. 하나를 수행한다고 해서 다른 하나가 수행되는 것은 아니며, 하나를 삭제해도 다른 하나가 삭제되지 않습니다.
- GitHub, GitLab, Google 및 Microsoft 로그인
- 동일한 계정의 패스키 및 2단계 인증
- 로그인 정보와 배포 자격 증명은 별도로 유지됩니다
자주 묻는 질문
어떤 소스 제어 공급자를 연결할 수 있나요?
GitHub 및 GitLab. 이미 작업 중인 계정을 연결하시면 해당 리포지토리에서 배포하고, 푸시 웹훅을 등록하며, 원하시는 경우 사이트 파일을 반대 방향으로 다시 동기화할 수 있습니다. 두 서비스 모두 동일한 연결 계정 인터페이스를 통해 처리되므로, 아래의 모든 내용은 두 서비스 모두에 적용됩니다.
GitHub 또는 GitLab으로 로그인할 수 있나요?
예, Google 또는 Microsoft로도 가능합니다. 이메일 주소 및 비밀번호와 함께 이 네 가지 중 어느 것으로든 Zinn Digital® 계정에 로그인하실 수 있습니다. ID 레이어가 핸드셰이크를 처리하므로 당사는 공급자 비밀번호를 절대 볼 수 없습니다. GitHub로 로그인하는 것은 배포를 위해 GitHub를 연결하는 것과는 별개의 작업이며, 둘 중 하나만 하거나 둘 다 하거나 둘 다 하지 않으실 수도 있습니다.
저장소를 어디에 배포할 수 있나요?
정적 사이트 또는 빌드된 사이트를 위해 Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps 또는 AWS Amplify로 배포하거나, 리포지토리와 사이트 파일이 양방향으로 동기화 상태를 유지하는 자체 관리형 호스팅으로 배포할 수 있습니다. 사이트의 대상을 직접 선택하십시오. 리포지토리 연결은 어느 방식이든 동일합니다.
사이트를 직접 제작해 주실 수 있나요, 아니면 이미 제작된 상태여야 하나요?
둘 다 가능합니다. 게시 모드에서는 브랜치를 있는 그대로 가져와 지정하신 디렉터리를 게시합니다. CI 모드에서는 제공업체의 자체 파이프라인이 빌드 명령을 실행하고 결과물을 별도의 게시 브랜치에 커밋하며, 당사는 이를 다른 참조와 마찬가지로 가져옵니다. 두 번째 방식은 비밀 정보와 캐싱이 이미 구성되어 있는 자체 CI 내에서 빌드를 유지합니다.
푸시가 자동으로 배포됩니까?
기본적으로 그렇습니다. 저장소에 웹훅을 등록하며 지정하신 브랜치로 푸시하면 배포가 시작됩니다. 이 기능을 끄고 웹훅을 유지할 수도 있으며, 이는 생각보다 유용합니다. 전달 내역이 계속 기록되므로 당사가 조치를 취하도록 허용하기 전에 푸시가 도착하는 것을 확인할 수 있습니다.
양방향 동기화란 무엇인가요?
저희 하드웨어에서 수행된 편집은 귀하의 브랜치에서 커밋이 되며, 귀하의 브랜치에 있는 커밋은 사이트에 다시 반영됩니다. 귀하가 직접 켜기 전까지는 꺼져 있습니다. 이를 켜는 것은 다른 사람의 저장소에 영향을 미치는 결정이며 저희가 귀하를 대신하여 결정하지 않기 때문입니다. 동기화할 디렉터리는 귀하가 직접 선택합니다 — 일반적으로 테마나 플러그인이며, 4만 개의 WordPress 코어 파일이 아닙니다.
양쪽이 모두 변경되면 어떻게 됩니까?
아무것도 덮어쓰지 않으며 아무것도 푸시되지 않습니다. 동기화가 중단되고, 브랜치가 기준이 된 커밋을 넘어 이동했음을 알리며, 저장소를 유지할지 사이트를 유지할지 어느 쪽을 원하는지 묻습니다. 한 번도 동기화되지 않았고 이미 커밋이 있는 브랜치를 가리키는 사이트 또한 별도의 고유한 상태이며, 어느 쪽이 맞는지 추측하는 대신 직접 확인을 요청합니다.
내 액세스 토큰은 어떻게 보호되나요?
연결을 생성하기 전에 필요한 권한을 표시하고, 입력 시 공급자의 자체 API를 통해 토큰을 검증하므로 유효하지 않거나 범위가 잘못된 토큰은 전혀 저장되지 않으며, 그런 다음 Vault에 기록합니다. 해당 토큰은 당사의 코드, 로그, 환경 파일 또는 명령줄에 절대 닿지 않습니다. 원하실 때 언제든지 공급자 측에서 취소하거나 여기에서 연결을 삭제하십시오.
제 푸시를 실제로 수신하고 계신지 어떻게 알 수 있나요?
저장소 카드에는 공급자가 마지막으로 당사에 전달한 시간과 전달 내용이 표시됩니다. '전달된 적 없음'은 해당 화면에서 가장 유용한 단일 진단 정보입니다. '연결되었지만 전달된 적 없음'은 범위가 잘못 지정된 토큰이나 차단된 전송의 전형적인 모습이며, 다른 곳에서는 이를 확인할 수 없기 때문입니다. 모든 전달은 당사가 처리하기 전에 서명 검증을 거칩니다.
Footprint-Free 라인에서 Pages 배포를 사용할 수 있습니까?
제공되지만 플래그가 지정되어 있습니다. GitHub Pages 및 GitLab Pages는 제공업체 인프라와 공용 github.io 및 gitlab.io 호스트 이름을 공유하며, 이는 해당 라인이 방지하고자 하는 검색 발자국(footprint)에 해당합니다. 발자국 없는(zero-footprint) 네트워크를 구축하려면 격리된 호스팅에 배포하십시오. 그 밖의 모든 곳에서 Pages는 최고 수준입니다.
왜 명시적으로 Vercel을(를) 선택해야 하나요?
무료 티어는 비상업적 용도로만 라이선스가 부여되기 때문입니다. 안전한 경우 연결하신 계정으로부터 대상을 유추하지만, Vercel은 해당 유추 대상에서 의도적으로 제외됩니다. 계정을 연결하더라도 라이선스가 허용하지 않는 곳에 상업용 사이트가 임의로 배포되어서는 안 되기 때문입니다. 직접 선택하시면 다른 옵션들과 완전히 동일하게 작동합니다.
무엇이 언제 배포되었는지 확인할 수 있습니까?
예. 모든 배포는 게시된 커밋, 실행 시간 및 완료 상태를 기록하며, 사이트의 배포 탭에는 라이브 URL과 함께 기록이 표시됩니다. 배포는 백그라운드에서 실행되므로 로딩 스피너를 보며 기다릴 필요 없이 빌드가 완료되는 즉시 페이지가 업데이트됩니다.
관련 항목
리포지토리에서 배포
카드 등록 없이 14일 무료 체험을 시작하고, GitHub 또는 GitLab을 연결한 뒤 사이트를 브랜치에 연결하세요. 엣지 호스트에 배포하거나 파일이 양방향으로 동기화되는 당사의 호스팅에 배포할 수 있습니다.
무료로 시작하기