ソース管理

すでにお使いのリポジトリからデプロイ — 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 に保存されており、他の場所には保存されません

私たちのコード内でも、環境ファイル内でも、ログ内でも、コマンドライン上でもありません。それを使用するワークロードによって、使用される瞬間に解決されます。

サイトごとに選択された複数のアカウント

個人アカウントと組織のアカウント、または2つの組織のアカウントを接続します。各サイトはどちらからデプロイするかを選択するため、クライアントのリポジトリとご自身のリポジトリが認証情報を共有することはありません。

リポジトリが配置される可能性のある9つの場所

8つの管理対象エッジホストと当社独自のフリート。送信先は接続ではなくサイトのプロパティであるため、同じリポジトリから1つのブランチを 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 データとともに、実行中の他のすべての要素と並んでダッシュボードに表示されます。

外部サイトの割り当て →

またはここで編集

ブラウザ内エディタは双方向同期によってプッシュバックされるのと同じファイルを処理するため、ダッシュボードからの迅速な修正が、後から誰も見つけられない変更ではなく、お客様のブランチへのコミットになります。

Web エディター →

双方向同期

リポジトリと公開中のサイトを、常に同期

これをオンにすると、サイト自体のファイルがブランチにコミットされ、そのブランチのコミットはサイトに反映されます。当社がホスティングするすべてのサイト、すべての回線で機能します。唯一の要件は、基盤となるマシンがそのファイルに対して Git を実行できることであり、これはプランから推測するのではなくサーバーに確認されます。

同期するディレクトリはお客様自身で選択します。WordPress をご利用のお客様は、4万個ものコアファイルではなく、自身のテーマの追跡を求めているためです。そして、有効にするまではオフになっています。同期を有効にすることは他者のリポジトリに関する決定であり、移行処理がお客様に代わって勝手に行うべきではありません。

  • 当社のハードウェア上での編集が、お客様のブランチのコミットになります
  • ブランチ上のコミットがサイトに反映されます
  • ドキュメントルート全体ではなく、1つのディレクトリ (テーマ、プラグインなど) を同期します
  • 既存のすべてのサイトを含め、デフォルトで無効
エディターで開かれたファイルと、リポジトリ内でコミットとして表示された同じファイル。

ディレクトリを公開するか、独自の CI にビルドさせてください

2つのモードがあり、違いはビルドが実行される場所です。どちらも同じ場所に行き着きます。私たちが取得して公開する参照であり、デプロイに対してコミットが記録されます。

  • 公開モードはブランチをそのまま取得し、指定されたディレクトリを公開します。空白の場合はリポジトリのルートを意味します。
  • CI モードは、プロバイダー独自のパイプラインでビルドコマンドを実行し、出力を個別の公開ブランチにコミットします。これは他の参照と同様に取得されます。
  • デプロイの公開元ブランチは常に明示的な名前で記録され、決して「デフォルトブランチ」とは表記されません。デフォルトは意図せず変更される可能性があり、どのブランチを公開したかを特定できない履歴は履歴とは言えないからです。
  • 自動デプロイはデフォルトで有効になっており、Webhook を削除せずに無効化できるため、処理を実行させる前に配信の到着を確認できます。
  • デプロイごとにコミット、結果、時刻が記録され、バックグラウンドで実行されます。ビルドの完了に合わせてページが更新されます。
  • 接続を解除すると、作成された Webhook のみがその ID によって正確に削除され、リポジトリ内の他の項目が削除されることはありません。

リポジトリから公開サイトへ

  1. アカウントを連携する

    GitHub または GitLab (「接続」の下)。権限はトークンを作成する前に一覧表示され、保存される前にプロバイダーに対して確認されます。

  2. サイトをリポジトリに向ける

    オーナー、リポジトリ、ブランチ、そしてディレクトリを公開するか、貴社の CI がビルドした成果物を取得するかどうか。その一環としてプッシュ Webhook を登録します。

  3. 押すか、ボタンを押してください

    指定されたブランチへのプッシュによってデプロイが開始されます。または、サイトの「デプロイ」タブからオンデマンドでデプロイすることもできます。ビルドはバックグラウンドで実行されます。

  4. 確認の上、必要に応じて再同期してください

    デプロイ履歴には、何がいつ公開されたかが表示されます。双方向同期をオンにすると、ここで行った編集がブランチへのコミットとして反映されます。

問題が発生した場合

「接続済みだが配信されなかった」は、お客様に実際にお知らせするステータスです

正常に見えるのに何も受信しないリポジトリ接続は、典型的なサイレント障害です。スコープが正しくないトークン、プロバイダー側でブロックされた配信、誰かが手動で削除したフックなどが原因です。これは他のどの画面にも表示されないため、リポジトリカードに直接表示されます。プロバイダーが最後にいつ配信したか、そしてどのような応答があったかを示します。

配信に対して処理を実行する前に署名検証を行いますが、すべてのプロバイダーに適用されると想定したスキームではなく、各プロバイダー固有のスキームを使用します。検証されない配信は拒否されて記録され、暗黙的に無視されることはありません。

  • カード上の最終配信日時とメッセージ
  • 空白のままにはせず、「未配信」と明記されます
  • 処理を実行する前にプロバイダーごとに署名を検証済み
  • 作成されたフックは、切断時に ID によって削除されます
Webhook の配信を受信し、何らかの処理をトリガーする前に検証しています。

ID

GitHub または GitLab でサインイン — または Google、または Microsoft

メールアドレスとパスワードに加え、GitHub、GitLab、Google、または Microsoft を使用して Zinn Digital®アカウントにサインインできます。アイデンティティレイヤーがハンドシェイクを実行するため、プロバイダーのパスワードを当社が閲覧することは一切ありません。また、ソーシャルアカウントを既存の Zinn®アカウントに連携するには、引き続きメールでの確認が必要です。

GitHub でのサインインとデプロイ用の GitHub の連携は、個別の決定であり個別の認証情報です。一方を行っても他方が行われることはなく、一方を削除しても他方が削除されることはありません。

  • GitHub、GitLab、Google、Microsoft でログイン
  • 同一アカウントでのパスキーと2要素認証
  • サインインとデプロイの認証情報は別々に保持されます
チーム用の委任アクセス
複数のユーザーが異なるプロバイダーを使用して1つのアカウントにサインインしています。

よくある質問

どのソース管理プロバイダーを接続できますか ?

GitHub および GitLab。既にご利用中のアカウントを連携していただければ、そのリポジトリからのデプロイ、プッシュ Webhook の登録、そしてご希望に応じてサイトのファイルを双方向に同期することが可能です。どちらも同じ連携アカウントの仕組みを経由するため、以下の内容は両方に適用されます。

GitHub または GitLab でサインインできますか ?

はい、Google または Microsoft でも可能です。メールアドレスとパスワードに加え、これら4つのいずれを使っても Zinn Digital®アカウントにサインインできます。アイデンティティ層がハンドシェイクを処理するため、弊社がお客様のプロバイダーのパスワードを確認することは決してありません。GitHub でのサインインはデプロイ用の GitHub 連携とは別個の機能です。片方のみ、両方、あるいはいずれも利用しないことを選択できます。

リポジトリはどこにデプロイできますか ?

静的サイトまたはビルドされたサイト向けの Cloudflare Pages、GitHub Pages、GitLab Pages、Netlify、Vercel、Render、Azure Static Web Apps、AWS Amplify へ、あるいはリポジトリとサイトのファイルが双方向に同期され続ける当社独自のマネージドホスティングへ。サイトの移行先はお客様が選択でき、リポジトリの接続方法はどちらの場合も同じです。

サイトを作成していただけますか、それとも事前に作成しておく必要がありますか ?

どちらでも可能です。公開モードではブランチをそのまま取得し、指定されたディレクトリを公開します。CI モードではプロバイダー独自のパイプラインがビルドコマンドを実行し、出力を個別の公開ブランチにコミットします。その後、他の参照と同様にそれを取得します。後者の方法では、シークレットやキャッシュがすでに存在するお客様独自の CI 内にビルドを保持できます。

プッシュは自動的にデプロイされますか ?

デフォルトでは、はい — リポジトリに Webhook を登録し、指定されたブランチへのプッシュによってデプロイが開始されます。これを無効にして Webhook を維持することもできます。これは想像以上に便利です。配信は引き続き記録されるため、当社がそれらに基づいて対応することを許可する前に、プッシュの到達を確認できます。

双方向同期とは何ですか ?

弊社のハードウェア上で行われた編集はブランチのコミットとなり、ブランチのコミットはサイトに反映されます。有効化は他者のリポジトリに関する決定であり、弊社がお客様に代わって判断することはできないため、お客様がオンにするまでオフになっています。同期するディレクトリはお客様自身が選択します。通常はテーマまたはプラグインであり、4万もの WordPress コアファイルではありません。

両側が変更された場合はどうなりますか ?

上書きされることも、プッシュされることもありません。同期は停止し、ベースとしたコミットよりもブランチが進んでいることをお知らせした上で、リポジトリを保持するか、サイトを保持するか、どちらを希望するかをお尋ねします。一度も同期されたことがなく、すでにコミットが存在するブランチを参照しているサイトも独自の独立した状態であり、どちらが正しいかを推測するのではなく確認を行います。

アクセストークンはどのように保護されていますか ?

接続を作成する前に必要な権限を表示し、入力時にプロバイダー自身の API でトークンを検証します。そのため、無効なトークンやスコープが適切でないトークンが保存されることは決してありません。その後でのみ Vault に書き込まれます。トークンが当社のコード、ログ、環境設定ファイル、またはコマンドラインに触れることは一切ありません。いつでもご希望の際に、プロバイダー側で失効させるか、こちらで接続を削除してください。

プッシュが実際に受信されているかどうかをどのように確認できますか ?

リポジトリカードには、プロバイダーから最後に配信が行われた日時とその内容が表示されます。「配信履歴なし」はその画面で最も役立つ診断情報です。「接続済みだが配信履歴なし」は、スコープが正しくないトークンやブロックされた配信と全く同じ状態を示しており、他の場所では確認できないためです。すべての配信は、対応を行う前に署名検証が実施されます。

Footprint-Free ラインで Pages のデプロイを使用できますか ?

提供されており、フラグが設定されています。GitHub Pages と GitLab Pages はプロバイダーのインフラストラクチャおよびパブリックな github.io と gitlab.io のホスト名を共有しており、これは検索エンジンのフットプリントとなります。まさにこのラインが回避するために存在しているものです。フットプリントのないネットワークを構築するには、代わりに隔離されたホスティング環境にデプロイしてください。それ以外の点では、Pages は最高水準です。

なぜ明示的に Vercel を選択する必要があるのですか ?

無料プランは非商用利用のみを対象にライセンスされているためです。安全である場合には、連携されたアカウントから推測して接続先を決定しますが、Vercel はその推測から意図的に除外されています。アカウントを連携することで、ライセンスで許可されていない場所に商用サイトが気付かないうちに配置されるようなことがあってはならないためです。それを選択すれば、他のものとまったく同様に機能します。

何がいつデプロイされたかを確認できますか ?

はい。各デプロイでは、公開されたコミット、実行日時、および終了ステータスが記録され、サイトのデプロイタブにはライブ URL とともに履歴が表示されます。デプロイはバックグラウンドで実行されるため、スピナーを見ながら待機することなく、ビルドの完了に合わせてページが更新されます。

リポジトリからデプロイ

クレジットカード不要の14日間無料トライアルを開始し、GitHub または GitLab を連携して、サイトをブランチに関連付けます。エッジホストに公開するか、ファイルが双方向に同期される自社のホスティングに公開します。

無料で始める