タグ付けされた質問 「git」

私たちは、gitでパスワードやキーの漏洩を防ぐために、プロジェクトでansible vaultを使用することを計画しています。 考えは、すべての機密データをプレーンファイルに入れ、パスワードを使用してansible-vaultでこのファイルを暗号化してからgitにプッシュすることです。 ファイルを復号化するには、ボールトのパスワードをansibleに渡す必要があります。3つの可能性について考えています。 サーバー環境変数内に保存します ansible-playbookコマンドのオプションとして渡します バージョン非対応のファイルに保存します。 ansible-vaultパスワードを保存するための最良の（そして安全な）方法である他のオプションはありますか？

26 ansible  git  security  practices  ansible-vault 

継続的に開発されたWebプロジェクト（製品ではない）には、現在gitフローにほぼ基づいた次の分岐戦略があります。 開発ブランチ：最新の作業バージョン マスターブランチ：リリースされるバージョン/リリースされるバージョン 機能ブランチ：開発中の機能 ホットフィックスブランチ：リリースバージョンの緊急バグ修正 マスターは読み取り専用で、開発ブランチまたはホットフィックスブランチからのプルリクエストによって更新されます。各更新により、リリース候補が構築され、ステージングシステムに展開されます。リリース候補は、手動の承認後に実稼働に展開されます。 フィーチャーブランチはオフに基づいて作成されている開発、または最後のマスターにマージされたことにコミットから。開発する機能ブランチからのプルリクエストが構築され、統合テストと受け入れテスト（自動および手動）が実行される無料のテストシステムにデプロイされます。テストとレビューに成功すると、PRはマージされ、次のリリースの一部になります（開発からマスターへのマージ）。 私の目標 これを簡素化し、開発ブランチを削除したいと思います。開発ブランチには主に歴史的な理由があり、常に正常にテストされたバージョンであるため、マスターから切り離しておく必要はないと思います。これを削除すると、追加のマージがなくなるため、リリースプロセスも簡素化されます。 次の制約があります。 リリースは予定されており、完全に自動化するべきではありません 機能ブランチは通常短命ですが、一部は数週間マージされないままになります（たとえば、再設計）が、同様にテストする必要があります（現在、開発のためのオープンプルリクエストとして） 場合によっては、通常のリリース以外で単一の機能をリリースして、事実上それを修正プログラムに変更する必要があります。現在の戦略では、機能ブランチをリベースし、直接マスターにマージできます ステージングでの外部システムとの受け入れテストが失敗した後、機能を保留する必要があることも起こります 移行についてわからない場合： 現在、テスト用のプルリクエストを作成し、リリース用のコミットをマージしています。これを統合できますか？ マスターが最新リリースより前である場合のホットフィックスの処理方法。ホットフィックスブランチからリリースを直接ビルドおよびデプロイする必要がありますか？ 既にマージされたリリースから除外されるべき機能に対処する賢明な方法はありますか？これらの場合、独立した開発ブランチは本当に利点ですか？とにかく、ほとんどの場合、手動でコミットを元に戻して元に戻すことになります。

20 git  release-management  builds  branch 

ansible-vaultコマンドを使用して、秘密を含むファイルを自動的に暗号化および復号化するために、gitでclean / smudgeフィルターを設定しようとしています。 ansible-vaultコマンドの特徴は、it等ではないことです（同じデータで呼び出されるたびに異なるバイナリを作成します）。 このブログページで提案されている実装から始めました。残念なことに、それは正しく機能しませんでした。汚れが呼び出されると（git checkout、または単にgitステータス）、秘密ファイルはgit用に変更されたように見えます。 だから、gitがインデックスにあるバイナリをクリーンフィルター処理された現在のファイルと比較するのではないかと思い、これらのスクリプトを次のように構築しようとしました。 #!/bin/sh -x # clean filter, it is invoked with %f if [ ! -r "$HOME/.vault_password" ]; then exit 1 fi tmp=`mktemp` cat > $tmp # get the plain text from the binary in the index tmphead=`mktemp` git show HEAD:$1 > $tmphead contenthead=`echo "embedded" …

20 git  ansible  ansible-vault 

JenkinsがGitとSVNをサポートしていることは知っています。Jenkinsは他にどのSCMツールをサポートしていますか？

17 jenkins  jenkins-plugins  git  linux  scm 

Gitの完全な改訂履歴があることは、開発プロセスの一部として多くの利点があります。 しかし、当社の製品はソースコードであり、コンパイルや処理を必要としないスクリプト言語を使用しているため、Gitの履歴が展開の負担になります。この例では、変更ごとにクリーンな仮想環境を展開し、単一のマシン。 履歴の量を減らす方法がいくつかあります。例えば、効率がブランチのリビジョンの深さに依存する浅いクローン、クローンの代わりにフェッチを実行しますが、リビジョンから履歴を取得して戻す、または完全に取得するリポジトリは一度必要に応じてプルしますが、これはディスク容量の点で無駄であり、信頼性が低くなる傾向があります。 Gitから履歴なしで1つのリビジョンを取得する方法はありますか？

14 git 

この.NETショップをsvnからgitに移行することに焦点を当てており、スイッチを切り替える前に解決策を見つけたいと思ういくつかの付随的な問題を特定しました。 この質問で特に質問しているのは、行末強制です。デフォルトでは、Windows用のgitは 'checkout crlf、commit lf'でインストールされます。これは、crlfの末尾のみで構成される（私が知る限り）ソースの束に対しては機能しません。 私は与えられた開発者が指示を与えられてもこれを正しく設定することを盲目的に信頼していることを知らないので、次のいずれか（または両方）を検討していますが、ここの誰かが別のルートを行った場合は興味がありました。 lf行の末尾（またはすべてのlf行の末尾）をチェックし、そのイベントで拒否する事前コミットフック。 グローバル設定に「現状のまま」を設定する、開発者に配布されるインストールスクリプト。 PSこれを書いているときに、svnからgitへの最初の変換がデフォルトの方法をコミットする可能性があり、人々がデフォルトに固執している限り、それもかなりシームレスです。デフォルトではない「現状のまま」でgitをインストールした.NETショップでgitを使用して開発者だったので、私もそこに自分の問題を作成しました（到着する前にすべてデフォルトになりました） 。ですから、私はまだ何らかの強制メカニズムに傾いています。

13 git  scm  windows 

Travis CIを使用してファイルをデプロイしたいのですが、タグ付きコミットでのみ機能します。ブランチにコミットするとき、警告があります： これはタグ付きコミットではないため、リリースプロバイダーでのデプロイメントをスキップします。 Travis CIを使用してブランチコミットにデプロイする方法はありますか？ 明確にするために、コミットにタグを付けると機能しますが、指定したブランチの各コミットにファイルをデプロイしたいと思います。

11 git  release  deployment  travis-ci  github 

すべて、有効な証明書チェーン（OpenSSLでテスト可能）がありますが、どういうわけかこれらの証明書をロードするようにGitに指示することができません。 私が得る同じ「信頼できないルート権限」エラー（SEC_E_UNTRUSTED_ROOT）を独立して、既存または偽の証明書チェーンファイルにするかどうか、私のgitの構成ポイントの。 詳しくは、添付のスクリーンショットをご確認ください。 .gitconfig偽のファイルに使用する設定： sslCAInfo = C:/tmp/foobar.crt または、OpenSSLで動作する実際のファイルの場合： sslCAInfo = C:/tmp/ca-bundle.crt コンソールの筆記録： C:\tmp>openssl version OpenSSL 0.9.8h 28 May 2008 C:\tmp>git --version git version 2.12.2.windows.2 C:\tmp>git config --list http.sslverify=true http.sslcainfo=C:/tmp/ca-bundle.crt C:\tmp>dir 24.04.2017 13:45 10.875 ca-bundle.crt c:\tmp>openssl s_client -state -connect https://mygithost:443 -CAfile .\ca-bundle.crt Verify return code: 0 (ok) C:\tmp git clone https://mygithost/bitbucket/scm/my.git …

10 git  windows  ssl 

私たちは会社として成長しており、製品が拡大し、DevOps関連の活動と取り組みも成長しています-展開パイプラインやその他のプラグインを使用して、Bambooからより柔軟で構成可能なJenkinsに切り替えました。Ansibleに切り替え、Dockerを社内のあちこちで使い始めました。 これらすべてのものには、ある程度のコーディングまたは構成が必要です-Ansibleスクリプトと構成、Jenkinsグルーヴィーなスクリプト、Dockerfiles、YAML構成。 今のところ、我々はのためのハイレベルのディレクトリに別の「OPS」リポジトリを作成したjenkins、ansible、docker及びother（ひどい名前であるが、現在はすべて「その他」DevOpsチームのためのオートメーションのものがあります）。 私たちのアプローチは正しく感じられず、拡張できない場合がありますが、DevOps関連のコードをコードリポジトリに保持するためのベストプラクティスと推奨事項は何ですか？

10 jenkins  docker  ansible  git  repository 

CI-CDを推進し始めたばかりであり、新しいステップとして、スタックを最新のグリーン開発で数時間に1回更新することを試みます。私はGit / Bitbucketにかなり慣れていないため、Jenkinsが行うチェックアウトで、「最後のコミット」がブランケットステートメントとしてだけでなく、Jenkinsによって緑色にマークされていることを確認する方法を理解できません。 我々は持っているのNotifierのBitbucketのビルド・ステータスのBitbucketは、コミットが私たちのユニットテストを実行した後に緑のあるトラックを行いますので、インストールされたプラグインを。この情報を活用して正しいコミットが選択されていることを確認する方法はありますか？

10 jenkins  git  bitbucket  bcbsn 

私はジェンキンスのマルチブランチパイプラインを使用しています。ブランチがマージされ、削除された場合、ジェンキンスはブランチをパイプラインからも削除します。 これは素晴らしいですが、ブランチが削除されたときにコマンド/スクリプトを実行したいのですが、ブランチが削除されたときにjenkinsにコマンドを実行させるにはどうすればよいですか？ジェンキンスがブランチを削除する前にジョブをトリガーする方法はありますか？ 編集：私はbitbucketを使用していることを追加する必要があります。Jenkinsがマルチブランチパイプラインのブランチをパージするときにイベントをトリガーできれば、すばらしいでしょう。理想的には、私のgitプロバイダーが何であるかは問題ではありません。

9 jenkins  git  jenkins-plugins  jenkins-pipeline  jenkinsfile 

バックグラウンド 私のバックエンドチームが作成したプルリクエスト（PR）ごとにiOS / Androidアプリでテストを行う必要がある非技術的なQAチームを獲得しました。 質問 これが私がやりたいことです。バックエンドエンジニアがbitbucketでPRを作成するたびに、作成したJIRAの問題と一致するPR gitブランチのコードを開発サーバーのサブドメインに自動的にデプロイするスクリプトが欲しいです。 たとえば、PRがBAC-421に対応するというjiraの問題を想定し、エンジニアがPRを作成するとすぐに、スクリプトが作成したコードをAWS EC2にデプロイし、QAがアプリをwww.bac421.mydevdomainにポイントできるようにします。 com これを行う最良の方法は何ですか？私は専門の技術者です。 更新-環境仕様 ここに私たちの環境の分解があります-バックエンドはlaravel 5.3を使用します-それはAWS EC2にデプロイされます- 自動デプロイメントにforgeを使用します（空想的なものはありません。このスクリプトを実行するだけです： cd /home/forge/default git fetch --tags git pull origin master git describe composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader echo "" | sudo -S service php7.1-fpm reload if [ -f artisan ] then php artisan migrate …

9 git  deployment  bitbucket  git-hooks 

私の会社はCI / CDを統合しています。これまでのところ、私が理解しているものからCIを実装しています。現在、開発者がコードをgitリポジトリにプッシュすると、CIパイプラインが実行されます。 現在、CIパイプラインには、プロジェクトの構築と静的コード分析の実行が含まれており、コーディング標準に適合していることを確認しています。次にテストを実施します。ビルドと静的コードの分析には、現在約3分かかります。私が読んだことからすぐに問題を修正することは、CI / CDにとって重要です。単体テストを追加すると、パイプラインの実行に約10分かかることが予想されます。 したがって、私の質問は、CIパイプラインが完了するのを待つか、次のタスクに進んでパイプラインの問題が存在する場合はそれを修正するためにプル/マージリクエストを行う必要があるかということです。または、座ってパイプラインの実行を監視する必要がありますか？

8 continuous-integration  git  continuous-delivery 

一部の読者にとってこの質問は信じられないほど些細なことのように思われますが、開発者であるが、マニュアル以外の方法でアプリをデプロイした経験がほとんどない人としては、ある意味で、期待どおりに、それが理解できることを願っていますさまざまなアプローチやツールの数を確認するのは非常に難しいので、正しい方向に進むために少しアドバイスをすることができました。 私は開発者ですが、今は限られた時間の中でのみです。これまで私はJavaを使用してWebアプリケーションを構築しており、warファイルをTomcat環境にデプロイして、物事を適切にカプセル化しておくことにかなり満足しています。 私は現在PythonとDjangoで作業していますが、デプロイする必要があるポイントに近づいたら、できる限り自動化し、確実にデプロイできるようにするための確固たるdevopsワークフローをセットアップしたいと思いますが、使用例は比較的単純です。自分のニーズに合わせて過剰に設計され、時間の多大な投資を必要とする大きな脂肪のツールセットを学習したくないので、アプリのコーディングを使用します。 ですから、大きな開発エコシステムのセットアップと学習に膨大な時間を費やすことなく、確実にアプリをデプロイして管理することができる中立的な立場を探しています。 さらに詳細... 環境 Macで開発し、PyCharmを使用してDjango 2、Python 3をビルドしています。 ソフトウェアのバージョン管理にはgit（githubではない）を使用しています。 私は他の言語やスクリプト言語に慣れており、bashはあまり好きではありませんが、いくつかの（おそらくかなりアマチュアっぽい）bashスクリプトを書いています。私はPerlにも手を出しましたが、これは実際には手を出すための言語ではないことに気付きました（つまり、適切に学習するために時間を費やす必要があります）。 VPS環境、おそらくDigitalOceanに展開するつもりです。 私のアプリはミッションクリティカルではありませんが、サイトがダウンした場合、それがアプリを再起動するか、サーバーを再起動するか、別のサーバーに移動するかにかかわらず、ダウンした場合に確実に回復する方法が必要です（またはその他）。 特定の要件 アプリを受け取るための新しい環境をセットアップする機能。 これまで私が学んでいる間、これは手動で行われ、それを行うたびに、新しいDropletをゼロから始めました。これをはるかに単純化（自動化）して、緊急時に新しい環境をセットアップしなければならない場合でも確実に行えるようにしたいと思います。 可能な限りライブと同じステージング環境にアプリをデプロイする機能。理想的には、継続的インテグレーションアプローチを使用してgit pushによってトリガーされる自動化プロセス（これまで行ったことがない）と同じです。 ステージング環境でのアプリに満足したときに「ボタンを押す」機能。理想的には自動的にライブ環境にプッシュします。 サイトを監視する方法（ページへの投票だけで十分です） ライブサイトでアプリまたはサーバーの障害から回復する必要がある場合に、ライブサイトを別のサーバーに切り替える方法。青緑のアプローチがうまくいくと思いますか？ 何を試したり検討したりしましたか？ Djangoアプリを使用してライブ環境を手動で設定し、変更があった場合は新しいコードベースを手動でコピーします。これは人為的なミスが発生しやすいと感じており、デプロイでミスをすると回復不可能なエラーが発生することを恐れています。 Docker。Dockerについて知ったときは夢が叶ったように思えますが、少し実験と研究を行った後、これを実行して管理するためにどれだけ多くのことを学び、知る必要があるかに悩んでいます。いったん機能するようになるとリスクは非常に低くなるので、これは価値があるかもしれませんが、現時点では、私が期待しているよりも大きな時間を投資しているように感じます。 Bashスクリプト。それらを使用して、元の環境をセットアップし、アプリの更新などの特定のタスクを実行します。これについての私の心配は、スクリプトがテストを必要とするコードになることであり、この方法で信頼できるツールセットを構築するには多くの時間がかかるのではないかと心配しています。 私は、フローティングIPアドレスに関するDigital Oceanのオプションと、かなり賢明なように見える「ブルーグリーン」アプローチのために2つのサーバーを使用する機能を見てきました。このルートに進んだ場合でも、展開を自動化できる必要があります。 だから...私は、リスクの最小化（例：更新によってライブアプリが破損するリスク、または障害から回復できなくなるリスク）と時間の最小化の間の適切なバランスを見つけるdevopsアプローチに関するアドバイスを探しています環境とワークフローをセットアップするために必要な投資。

8 continuous-integration  git  python 

開発とテストのための新しいステージングプロセスを作成する必要があります。 常に、活発に開発およびテストされているgitブランチは約4つだけです。各gitブランチ内には、実行する必要のあるデータベースエボリューションスクリプト（ストレートSQL）と、より重い処理のためのバックエンドからのエボリューションスクリプトがあります（これらは、データベースを実行する管理者資格情報を使用してアプリ内で呼び出す必要があるHTTPルートです）移行や、前述のプレーンなSQL進化スクリプトでスクリプトを作成することが困難または不可能であるその他の変更）。 私たちのライブDBは、適度なサイズの4.2 GBです。セットアップの準備ができて、使い捨ての真新しいDell PowerEdgeサーバーがあります。 次の質問についてのアドバイスと、経験豊富なDevOpsがこれにどのように取り組むかを知りたいです。 ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？これらのブランチは、QAに合格し、マスターにマージされて解放されると、頻繁にポップアップして消えます。 各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？各ブランチは、マージされるまで相互に互換性があるとは限らないさまざまな方法でDBに変更を加える場合があります。 これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？ これをすべて設定する方法について少し迷っていますので、これ以上の入力は大好きです。現在のワークフローは関係者全員にとって困難です。開発者は完全に分離されたアプリのローカルコピーをローカルで実行しており、QAは3〜4台のラップトップをローテーションしてステージング「サーバー」として機能させます

8 git  testing  builds  branch  mysql