2017-04-05 10 views
0

今後のプロジェクトでGCFを使用することを検討していますが、最後にはまだ文献がないようです。Google Cloud機能とCI/CD

すべての例とチュートリアルでは、機能を手動で展開することにかなり重点を置いています(gcloudコマンドを使用)。しかし、当社の機能をCI/CDワークフローに統合したいと考えています。

CIの部分は簡単なので、私たちの質問はCDの観点からプロジェクトを構成する方法です。理想的には、プッシュで機能を展開することが理想的です(例えば、マスターブランチからプロダクション、開発ブランチから開発環境など)。

機能ごとに1つのrepoを使用すると、これも非常に簡単です。しかし、それほど簡単ではないアプリケーションでは、何百もの機能を持つことが予想され、機能ごとのレポを非常に面倒にすることになります。ファンクションごとのリポジトリのもう1つの問題は、共有ロジック(たとえばJWTまたはCORSを考える)を使用できないことです。

もう1つの方法は、1つのリポジトリをすべての関数で使用し、次に--source-pathオプションを使用してデプロイする関数を指定することですが、GCFがそのパスをチェックアウトするので共有コードを使用できなくなります。階層の上にあるコードをインポートすることはできません。また、すべてのアプローチに対する1つのレポは、プッシュ・ツー・デプロイを行うことを信じられないほど困難にするでしょう。

このようなGCFプロジェクトの設定方法を教えてください。

+0

それは意見に基づいていませんか? –

+0

@SagarVは詳しく述べていますか? –

+0

ファンクションごとにレポが発生した場合のコード共有の問題をどのように解決する予定ですか? – QuestionAndAnswer

答えて

2

Serverlessフレームワークには、すべての、または一部の機能を展開するためのすばらしいユーティリティがあります。

https://serverless.com/framework/docs/providers/aws/guide/deploying/

私はGoogleクラウド機能プラグインでプレイしていないが、それはまともなようです。

https://github.com/serverless/serverless-google-cloudfunctions

それはサブディレクトリ内の個々の機能を導入することになる - 彼らは変更されている場合にのみ...あなたは少しbashのfooのを使用する必要があります。

あなたは、

git diff --name-only HEAD 878850 | sed 's/\(.*\)\/.*/\1/' | uniq | while read line ; do cd $line && gcloud beta functions deploy ; done 

がうまくいけば、これはビットを助けなど、特定のタグ以降に変更された各ディレクトリを通して、ループは、それは間違いなく、これらのための初期の頃だGitのブランチに基づいてのgcloudプロジェクトを設定することができますワークフローの種類。

関連する問題