このソフトウェアは、地理的に分散した小売店で動作するように設計されています。
最初に、ソフトウェアはさまざまなディストリビューションおよびアーキテクチャ用のdebパッケージのセットとしてクライアントに提供され、これらのdebファイルをインストールする前に依存関係としてインストールする必要があるパッケージのリストが含まれていました。
ftpを介してファイルを配布することからリポジトリを作成し、構成管理システムを起動し、継続的インテグレーションサーバーの実装を開始するまでの進化の道筋を教えてください。
生命の起源
したがって、ソフトウェアはQtで書かれた商用開発であり、すべてが2つのアーキテクチャ（i386とamd64）およびいくつかのディストリビューション用にアセンブルされています。 現時点では、これを決定しました：Debianの最近の2つまたは3つのリリースとUbuntuからの最後の2つのLTS。 さらに、クライアントで使用されるいくつかのバージョン（現在3つ）があります。
3つのバージョンがこのようになりました。ソフトウェアを購入すると、クライアントにサポートが提供され、合理的な費用でソフトウェアの新しいバージョンが提供されます。 サポートの可用性に関係なく、マイナーバージョンの変更は無料で提供されます。 メジャー-またはサポートの存在下、または割引でのみ再販売。
バージョンはほとんどなく、クライアントのインストール数は少なかったものの、ftpは非常にコストがかかる可能性がありました。 これは次のように見えます：すべてのソースをdebパッケージにアセンブルした後、各クライアントのファイルのセット（バージョンによって異なります）がアーカイブされ、各クライアントのftpで独自のセクションに配置されました。 時間が経つにつれて、ftpはさまざまなクライアントから多くの同一のtar-sを蓄積しました。これらは時々削除する必要がありました。
時間が経つにつれて、クライアントが追加され、クライアントネットワークのサイズが大きくなり、ポイントのソフトウェアバージョンを更新することは別のタスクになりました。特に、ポイントの99％でインターネットがGPRSであった（そして今でも）ことを考慮してください。
パッケージの収集といえば。 debパッケージを収集したスキップは、元々「300年前」に英語でいくつかのマニュアルに書かれており、私見は完全に正確ではありません。 次の記事は、スクリプトをくまなく洗うのに役立ちました（著者に感謝したいと思います）。
進化の始まり
コンパイル済みパッケージを配布するという問題は、何らかの形でより正確な方法で提起されました。 「その後、Ostapが苦しんだ」（c）、彼はすべてのことを正しく行うことを決めたため、最小限の時間が日常業務に費やされました。
リポジトリをサポートするソフトウェアとしてRepreproが選択されました。 当時、彼が提供した機会は十分でした。
さらに、更新、多数のコンピューターの構成の経験に基づいて、構成管理ツールが必要でした。 GoogleとHabrが支援を求められました。 私はansible、chef、puppet、その他の名前を覚えていないシステムに精通しました。 設定、ドキュメント、エントリのしきい値、その他のパラメーターの組み合わせの理解度に応じて、 パペットが採用されました。 職長は人形にボルトで固定されました。 そして幸せが訪れました。
あまり時間はかからず、リポジトリ管理としてもっと違うものが欲しかった。 同じパッケージの異なるバージョンを同じリポジトリに保存する機能を除いて、Repreproはすべての人に適しています：そのため、何らかのリグレッションの場合に特定のバージョンに迅速にロールバックしたり、特定のデータセットで特定のバージョンのシステムの動作を迅速にテストしたりできます特定のハードウェア構成。
例として、あるクライアントがドキュメントの操作中にアプリケーションのクラッシュを検出しました。 開発者のコンピューターに設定された彼らのデータは疑いもなく飛び、すべてが開き、落ちなかった、それは素晴らしく機能した。 スタンドを組み立て、同じlinux、同じバージョンのソフトウェアを入れますが、すべてが正常に機能し、クラッシュしません。 彼らは可能な限り偏執的な行動を取り始めました。クライアントのマシン、ディスク、メモリ、プロセッサ、モニターの解像度、そして見た目を可能な限り近づけて別のマシンを組み立てました。 秋を繰り返した。 私たちは理解し始めました：私たちは本質がモニターの解像度にあり、むしろ、解像度そのものではなく、アスペクト比にあることを発見しました。 開発者と最初のテストマシンでは、モニターのアスペクト比は16：9で、2番目のテストは4：3でした。 その結果、qssの1行が落下につながると計算しました。 もちろん、これは大きな驚きでした。 これがこの例の目的です。 これらのテストの時点では、そのようなリポジトリはなく、組み立てられたマシンごとに、旧式の方法でscpを介してdebパッケージをコピーし、ハンドルを使用して依存関係をインストールし、パッケージ自体をインストールしてからチェックする必要がありました。 すべての依存関係を持つaptitudeを使用して数分でインストールする代わりに。
私はそれをググる必要がありました。 その結果、 記事はグーグル検索されました。 私はそれに記載されているオプションに対処し始めました。 私は何とか見ました：
- DAK-まったくマスターされていません。 「公式のソリューション」として始めましたが、残念なことに、gitが私に引き寄せたプロジェクトツリーをどうすればよいのか理解できませんでした。 したがって、彼はあまり気にせず、さらに読み続けました。
- 私が気づいた2番目の製品はミニダックでした。 そして、構成からすべてが明確であり、説明が多かれ少なかれ明確であるかのように。 リポジトリ名（mini-dakで言うとスイート）を作成できないようにしたかっただけです。 たとえば、次のようにリポジトリへのパスを取得します。
deb http：// SERVER_NAME / squeeze-evolution-beta non-free
Aはできません。なぜなら、スクリプトの深さのどこかで、変数名が「-」という記号で作成されており、bash-eでは機能しないからです。 ファイルを使用してスクリプトを変更する試みは失敗しました。なぜなら、bashでのプログラミングのレベルは、それらを書いた人のレベルに達していないからです。 - レビューの3番目のオプションが適切に選択されました。 そして、このツールが適しているようです。
適切に作業する
適切なドキュメントは非常に詳細であり、例もあります。 さらに、bash-completionがあります。
適切な可能性は非常に広く、以下では使用するコマンドのみを示します。 興味のある方は、製品サイトをより深くお勧めします 。
リポジトリの作成：
すべてのパラメーターを使用してすぐに作成できます。
aptly repo create -comment="Wheezy prehistoric" -distribution="wheezy-prehistoric" -architectures="i386,amd64,all" -component="non-free" wheezy-prehistoric
後でパラメーターを追加して、そのように作成できます。
aptly repo create wheezy-prehistoric
パラメータを変更する
パラメーターを一度に1つずつ変更します。
aptly repo edit -comment="Wheezy prehistoric" wheezy-prehistoric
または一度に：
aptly repo edit -comment="Wheezy prehistoric" -distribution="wheezy-prehistoric" -architectures="i386,amd64,all" -component="non-free" wheezy-prehistoric
既存のリポジトリを表示する
aptly list
リポジトリ情報の取得
一般情報：
aptly show wheezy-prehistoric
パッケージリスト情報：
aptly repo show -with-packages wheezy-prehistoric
リポジトリーへのパッケージの追加
単一ファイル：
aptly repo add wheezy-prehistoric build//Debian-wheezy/chameleon-core_1.3.0-wheezy46_amd64.deb
カタログ全体：
aptly repo add wheezy-prehistoric build//Debian-wheezy
追加するとき、ファイル/ディレクトリへのパスのオートコンプリートの欠如に多少混乱しました
リポジトリ公開
aptly publish repo wheezy-prehistoric
パブリケーションを削除
aptly publish drop wheezy-prehistoric
リポジトリグラフを取得
aptly graph
スナップショットのサポート、ミラーの作成、リポジトリ間でのパッケージの移動、依存関係のサポート、公開されたリポジトリを操作するための組み込みHTTPサーバーもサポートされています。
私が著者に書いた1つの特異性があります-プールはすべてのリポジトリに共通の1つのことであり、異なるリポジトリに同じ名前のファイルがある場合のみ正しいですが、これらのリポジトリを論理的に公開するときに異なるコンテンツとサイズのメッセージはありません少なくとも何か書くことがありました。 また、プールには最初に公開されたリポジトリのファイルが残ります。
ところで、著者は非常に迅速に反応し、 バグトラッカーでタスクを作成しました。
進化は続く
現時点では、バッグは体外装置のハンドルで収集されています。 良くないもの。 Jenkinsの実装はすでに始まっています。 CIで利用可能なツールの全リストから選ばれたのは彼でした。 TeamCityは最初にインストールされましたが、完全に無料で機能が低下しない他のプロジェクトがあるため、ライセンスのコストは理解されませんでした。 少なくとも今のところはそう見えます。 Jenkinsの操作中に何らかの理由でその機能が十分ではない場合（プラグインが非常に多いにもかかわらず、ほとんど信じられない場合）、より良いものに変更します。
PS
記事の終わりに要約したいと思います。
この記事のアイデアは素晴らしいツールを説明することでした-適切に オープンスペースで、Habrは彼について何も見つけませんでした。 「ここにツールがあります-それを使用できます」というスタイルで言うと、私はそれがおもしろくないことを発見しました。 自分の組織がどのように開発され、どのツールを同時に使用したかを読み、個人的な例を使用して有用なツールにコミュニティの注意を引くことは、はるかに興味深いと判断しました。
ご清聴ありがとうございました。