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

1
「すべての製品用の1つの大きなVCSリポジトリ」組織モデルから「多数の小さなVCSリポジトリ」モデルへのスムーズな移行を実現する方法
いくつかのVCSシステムのリポジトリに保持されている製品のコードベースが、そのコードベースがほぼ間違いなくいくつかの製品を含んでいると見なされるポイントに進化するという一般的なシナリオです。それぞれが単一の製品専用の複数のVCSリポジトリにコードベースを分割すると、いくつかの利点を活用できます(以下の肥大化リポジトリモデルよりもVCSリポジトリごとに製品を持っている利点を参照)。技術的な面では、ほとんどのVCSがこの操作をサポートしているため、コードベースの分割はかなり簡単な手順です。ただし、この分割により、自動化されたテスト、継続的な配信、サービスの統合または監視に関連するエンジニアリングの問題が発生する可能性があります(分割によって発生した問題を参照してください)。)したがって、このような分割の実行を計画している組織は、この移行をできるだけスムーズに、つまり、配信を中断せずにパイプラインを監視する方法を知る必要があります。これの最初のステップは、おそらくプロジェクトの概念と、モノリシックコードベースでの分割の詳細を理解することです。 この質問への回答では、私は見たいです: 製品とは何かを実際に定義する試み。これは、既存のコードベースで製品を実際に描写するための実用的な基準を提供します。 この作業定義に従って、実際に分割を実行する計画を作成します。コードベースがContinuous-IntegrationおよびContinuous-Deliveryを実装する完全に自動化されたsdlcによって処理されるという単純な仮定を立てることができます。つまり、各ブランチは現在のコードベースに実装された自動化されたテストスイートによって検証され、各「マジック」ブランチにマージされるたびに、テストおよびデプロイされる製品アーティファクトが生成されます。(製品のアーティファクトは、たとえばソースtarball、ドキュメント、バイナリソフトウェアパッケージ、Dockerイメージ、AMI、unikernelです。) そのような計画は、それを回避する方法を説明すれば満足です 分割によって提起された問題 自動化されたテスト手順は、既存のモノリシックリポジトリとスプリットリポジトリにどのように関連していますか? 自動化された展開手順は、既存のモノリシックリポジトリと分割リポジトリにどのように関連していますか? 自動展開手順自体のコードはどこに保存されていますか? 保存されたインフラストラクチャ、監視、および高可用性戦略はどこにありますか? 開発者が一度に1つのコードベースのみを必要とすることを保証する方法(ただし、他のコードベースのアーティファクトを使用可能)。 git-bisectのようなツールはどのようにできますか 限界メモ:肥大化したリポジトリモデルよりもVCSリポジトリごとに製品を持つことの利点 特定の製品のコードベースを保持するいくつかの小さなリポジトリがあると、「肥大化したリポジトリ」アプローチに比べて次の利点があります。 肥大化したリポジトリでは、製品が不安定なときにリリースをロールバックすることは困難です。これは、履歴が他の製品履歴と混在しているためです。 肥大化したリポジトリでは、プロジェクトの履歴やプルを確認するのが難しく、小さなリポジトリでは、この情報を読む可能性が高くなります。(これは、svnとは異なり、サブツリーをチェックアウトできないgitのようなVCSに固有の場合があります!) 肥大化したリポジトリを使用すると、開発時にさらに多くのブランチダンスを行う必要があります。N個のリポジトリがある場合、N個のブランチで並行して作業できます。リポジトリが1つしかない場合は、1つのブランチでしか作業できません。または、処理が面倒な作業コピーがたくさんあります。 いくつかの小さなリポジトリを使用すると、ログはプロジェクトのヒートマップを提供します。開発チームの知識普及のプロキシとして使用することもできます:3か月間レポXにコミットしなかった場合、レポXに取り組んでいるチームに私を割り当てて、開発を常に把握しておくとよいでしょうそのコンポーネントで。 小さなリポジトリを使用すると、コンポーネントの明確な概要を簡単に取得できます。すべてが単一の大きなリポジトリに格納されている場合、各コンポーネントの輪郭を示す明確なアーティファクトはなく、コードベースは泥の大きな塊に向かって簡単にドリフトできます。 小さなリポジトリにより、コンポーネント間のインターフェイスで作業する必要があります。しかし、私たちは良いカプセル化を望んでいるので、これはとにかくやるべき仕事なので、私はこれを小さなリポジトリの利点として数えます。 いくつかの小さなリポジトリを使用すると、複数の製品所有者を持っている方が簡単です。 いくつかの小さなリポジトリを使用すると、完全なリポジトリに関連し、自動的に検証できる単純なコード標準を簡単に作成できます。

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

1
シェフの料理本の整理
すべてのクックブックを保存するのに100%必要chef-repoですか?これは私には少し不便なようです。ソリューションのクックブックをアプリケーションのコードベースに保存するか、スタンドアロンのgitリポジトリとして保存したいと思います。 などのツールknifeがに存在する構成ファイルに依存していることは知っています.chef。

2
.NETプロジェクトのバイナリリポジトリの最良の方法
私は.NETプロジェクトに非常に慣れていないので、.NETプロジェクトのバイナリを保存するのに最適なツールはどれかと思います。.NETプロジェクトのバイナリをアーティファクトに保存するのはどのように良いのですか。その理由は何ですか。一般的に1つの回答が可能ですコメントは役に立ちます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.