外部ソース管理システムの使用 ​

Workatoからレシピをエクスポートする理由の1つは、一元化されたバージョン管理システムに保存できるようにすることです。 これはDevelopmentを行う多くの企業で標準的なプラクティスです。ただし、これを行うかどうかは、Workatoレシピで通常ソフトウェアDevelopment作業を行うスタッフがいるか、またはソース管理を業務に使用することに慣れていない、技術的な知識が少ないスタッフがそのタスクを行うかによって異なる場合があります。

以下の説明では、バージョン管理システムが“git”であることを前提としていますが、同じ一般原則は他のシステムでも使用できます。

一般にWorkatoでは、主にコードのスナップショットセットを維持し、チームがコードを提供および取得するためのステージング領域として外部バージョン管理を使用することを推奨しています。 それでも一定の価値があります。gitには異なるWorkato Environmentにまたがる一貫した履歴があり、gitアカウントを持つ全員がそれを確認できるためです。 また、レシピをgitリポジトリに安全にバックアップできることも保証されます。

ただし、レシピファイルがWorkatoの外部にある外部ソース管理システム内に存在する間に変更を加えることは推奨されません。 これは、Workato Environmentで変更が行われたときにWorkatoが実行するチェックと検証を受けられないため、リスクを伴う可能性があります。 また、この方法で行われた変更は、Workatoで表示されるバージョン履歴には表示されません。

目次 ​

• ライフサイクルマネジメントの計画
• エクスポート：レシピと依存関係のパッケージ化
• インポート: デプロイメント
• 外部ソース管理システムの使用 (現在)

WorkatoプロジェクトからGitHubリポジトリへのマッピング ​

WorkatoパッケージはGitリポジトリに直接マッピングできます。 1つのアカウントに複数のプロジェクトを含めることができ、各プロジェクトはパッケージを使用してバンドルされます。

以下の例では、Acme Workatoワークスペースに3つのプロジェクトが含まれており、それらはAcmeのGitHubアカウント内の3つのリポジトリにマッピングされています。

WorkatoパッケージからGitHubリポジトリへのマッピング

プルリクエスト（PR） ​

作成 ​

新しい各機能のDevelopmentは、Workato Developmentアカウントで開始されます。 機能が完了した後、レシピ開発者は最新バージョンのレシピに基づいてパッケージをビルドする必要があります。 パッケージは、プロジェクトのローカルGitリポジトリディレクトリに抽出し、解凍する必要があります。 次に、変更を機能ブランチにコミットし、中央のGitHubリポジトリにプッシュする必要があります。

最新パッケージを既存のGitHubリポジトリにコミット

GitHubに機能ブランチが存在するようになったら、開発者はレビューのためにプルリクエスト（PR）を送信できます。

GitHubでPRを作成

レビュー ​

1人以上のレビュアーがGitHubで新しいコードを確認し、コメントを追加できます。 開発者はレビューコメントに対応し、修正済みのコードでPRを更新する必要があります。 前述のように、まずWorkatoで変更を加え、テストしてから、再エクスポートすることを推奨します。

GitHubでレシピの変更を表示（以前のバージョンとの比較）

Environment間のマージとプロモーション ​

すべてのPRコメントが解決された後、機能ブランチをmasterブランチにマージできます。 この時点で、レシピおよびその他のアーティファクトのコードを、次のライフサイクルステージに対応する別のWorkatoアカウントにインポートできます。 これは、WorkatoのUIで直接エクスポートしてからインポートするか、GitHubコードをインポートに使用するWorkatoパッケージに再度zip圧縮するスクリプトによって実行できます。