構成管理のベストプラクティスの概要
種類。
少し前まで、ソフトウェア構成管理の本を探すことに戸惑っていました。 その結果、ほとんどが英語のSCMに関する文献のレビューが行われました 。 ファイナリストは3冊で、購入して勉強することにしました。 そして、それらの最初の-私にとっての「関心」と権限の両方の面で- 構成管理のベストプラクティス ：現実世界で機能する実用的な方法、ロバートアイエロがレスリーサックスと共同で書いた本） この名前は、「 最適な構成管理の実践 ：現実の世界で機能する実用的な方法」としてロシア語に翻訳できます。
注文して待っている間、私はそれをなんとか電子的に読むことができました（著作権侵害は恐ろしい悪です！） そして、この本は外部的にも内部的にも非常に快適です。 彼女は何について話しているのですか？
本は4つの部分に分かれています。
コアCMベストプラクティスフレームワーク 。 基礎、始まりの始まり。 それは、SCMが何であるか、なぜそれが必要なのか、SCMがどのような基本的なプラクティスで構成されているのかを簡単に、そしてビジネス上で伝えます。 興味深いことに、ここではバージョン管理は、より一般的な用語であるソースコード管理、つまり ソースコード管理。 これは意図的に行われます。なぜなら 著者は、バージョン管理（この領域は従来から呼ばれている）はコード管理の機能の1つにすぎないと考えています。 変更管理について多くのことが言われています。 繰り返しになりますが、この用語は従来の「バグ追跡」よりも一般的です。というのは、問題に対する高レベルのアプローチに関するものだからです。 ところで、これらの同じエラー追跡システムについて-言葉ではなく:)、製品変更のリクエストについてのみです。 製品のリリースには多くの費用がかかります。つまり、リリースとデプロイメントのリリース、および依存関係の制御です。
アーキテクチャおよびハードウェアCM 。 ここでは、SCM操作の2つの異なる側面について説明します。 まず、プロジェクトアーキテクチャの開発は、このプロジェクト自体の構成管理に基づくことができるという仮定が導入されます。 一見したところ大胆で奇妙な仮定ですが、興味深いことに述べられています。
第二に、ハードウェア構成管理に関する質問が提起されます。 ハードウェアが関与または開発されているシステムの開発のために-非常に必要なこと。 各ケースで実装が異なるため、HCM組織の基本のみを説明します。
CMのピープルサイド 。 全体のセクションは、実際には、論理的なルールと手順が非論理的で矛盾した人間の本性とどのように衝突するかについての物語です。 ここに、実用的な「プロセスの適正化」（プロセスを大きくしすぎないようにする方法）、変更に対する抵抗を克服するための闘争、および私が犯した間違いからの寛容な学習があります。 心理学者であり共著者であるレスリーによって書かれた「個性とCM：心理学者は職場を見る」という章があります。 名前は自明であり、セクション全体は人に関するものであり、それだけです。
コンプライアンス、標準、およびフレームワーク 。 名前が示すように、さまざまな標準やプロセステンプレートの研究と使用の経験が要約されています。 結局のところ、SCMフィールド自体は30〜40年にわたって存在していたため、ここでは長い間標準化されたアプローチがありました。 彼らについての話が続けられています。
著者について。 ボブ・アイエロは25年間（四半世紀！）SCM分野で働いてきました。 この間、私はいくつかの会社でそれを処理し、多くのプロジェクトに参加し、多くの人々に助言しました。 現時点では、相談に加えて、彼は構成管理計画に関するIEEE 828標準ワーキンググループの副長でもあります。 余暇は、SCMの問題の中心的なリソースであるCM Crossroadsの編集長を務めています。 言い換えれば、メジャーリーグプレーヤー、男と船。
本全体について。 全体を見ると、その本は奇妙なことに人々に関するものです。 説明されているすべてのアプローチは、常識と通常のエンジニアの日常業務の観点から説明されています。 ネガティブな経験が特に価値がある多くの個人的な例。
より価値のあるもの-これは、1つのソースに、標準（ドライフォーマル言語）または一般的な「世界の絵」がない別のソースで読めるものが含まれているためです。 この本は楽しい例外です。
本が必要なのはなぜですか？
コードを書いたりテストしたりすると、周りで何が起こっているのか、そしてマネージャーが突然、正しく生活する方法を説明し始めた人を突然連れて来る理由を見つけるのは、場違いになります。
あなたがリリースエンジニアまたはSMエンジニアとして働いているなら、あなたはそれを読まなければなりません;私は単に主題分野のより一般的な見方を見ていません。 読書後の頭の中の世界の完全な写真が提供されます。 次に進むべき場所を理解すると、さらに明確になります。
プロジェクトを管理している、または技術の専門家である場合は、一般的なプロジェクト活動と多くの共通点があるため、それを読むことを強くお勧めします。 とにかく、SMは基本的な領域であるため、多くのボトルネック、ボトルネックが発生するため、それらを克服するには、どちらにアプローチするかを知る必要があります。 そのため、Habrのブログ「プロジェクト管理」に投稿されました。
一般的に、あなたは正しい本を取る必要があります。 アマゾンに入りました 。
少し前まで、ソフトウェア構成管理の本を探すことに戸惑っていました。 その結果、ほとんどが英語のSCMに関する文献のレビューが行われました 。 ファイナリストは3冊で、購入して勉強することにしました。 そして、それらの最初の-私にとっての「関心」と権限の両方の面で- 構成管理のベストプラクティス ：現実世界で機能する実用的な方法、ロバートアイエロがレスリーサックスと共同で書いた本） この名前は、「 最適な構成管理の実践 ：現実の世界で機能する実用的な方法」としてロシア語に翻訳できます。
注文して待っている間、私はそれをなんとか電子的に読むことができました（著作権侵害は恐ろしい悪です！） そして、この本は外部的にも内部的にも非常に快適です。 彼女は何について話しているのですか？
本は4つの部分に分かれています。
コアCMベストプラクティスフレームワーク 。 基礎、始まりの始まり。 それは、SCMが何であるか、なぜそれが必要なのか、SCMがどのような基本的なプラクティスで構成されているのかを簡単に、そしてビジネス上で伝えます。 興味深いことに、ここではバージョン管理は、より一般的な用語であるソースコード管理、つまり ソースコード管理。 これは意図的に行われます。なぜなら 著者は、バージョン管理（この領域は従来から呼ばれている）はコード管理の機能の1つにすぎないと考えています。 変更管理について多くのことが言われています。 繰り返しになりますが、この用語は従来の「バグ追跡」よりも一般的です。というのは、問題に対する高レベルのアプローチに関するものだからです。 ところで、これらの同じエラー追跡システムについて-言葉ではなく:)、製品変更のリクエストについてのみです。 製品のリリースには多くの費用がかかります。つまり、リリースとデプロイメントのリリース、および依存関係の制御です。
アーキテクチャおよびハードウェアCM 。 ここでは、SCM操作の2つの異なる側面について説明します。 まず、プロジェクトアーキテクチャの開発は、このプロジェクト自体の構成管理に基づくことができるという仮定が導入されます。 一見したところ大胆で奇妙な仮定ですが、興味深いことに述べられています。
第二に、ハードウェア構成管理に関する質問が提起されます。 ハードウェアが関与または開発されているシステムの開発のために-非常に必要なこと。 各ケースで実装が異なるため、HCM組織の基本のみを説明します。
CMのピープルサイド 。 全体のセクションは、実際には、論理的なルールと手順が非論理的で矛盾した人間の本性とどのように衝突するかについての物語です。 ここに、実用的な「プロセスの適正化」（プロセスを大きくしすぎないようにする方法）、変更に対する抵抗を克服するための闘争、および私が犯した間違いからの寛容な学習があります。 心理学者であり共著者であるレスリーによって書かれた「個性とCM：心理学者は職場を見る」という章があります。 名前は自明であり、セクション全体は人に関するものであり、それだけです。
コンプライアンス、標準、およびフレームワーク 。 名前が示すように、さまざまな標準やプロセステンプレートの研究と使用の経験が要約されています。 結局のところ、SCMフィールド自体は30〜40年にわたって存在していたため、ここでは長い間標準化されたアプローチがありました。 彼らについての話が続けられています。
著者について。 ボブ・アイエロは25年間（四半世紀！）SCM分野で働いてきました。 この間、私はいくつかの会社でそれを処理し、多くのプロジェクトに参加し、多くの人々に助言しました。 現時点では、相談に加えて、彼は構成管理計画に関するIEEE 828標準ワーキンググループの副長でもあります。 余暇は、SCMの問題の中心的なリソースであるCM Crossroadsの編集長を務めています。 言い換えれば、メジャーリーグプレーヤー、男と船。
本全体について。 全体を見ると、その本は奇妙なことに人々に関するものです。 説明されているすべてのアプローチは、常識と通常のエンジニアの日常業務の観点から説明されています。 ネガティブな経験が特に価値がある多くの個人的な例。
より価値のあるもの-これは、1つのソースに、標準（ドライフォーマル言語）または一般的な「世界の絵」がない別のソースで読めるものが含まれているためです。 この本は楽しい例外です。
本が必要なのはなぜですか？
コードを書いたりテストしたりすると、周りで何が起こっているのか、そしてマネージャーが突然、正しく生活する方法を説明し始めた人を突然連れて来る理由を見つけるのは、場違いになります。
あなたがリリースエンジニアまたはSMエンジニアとして働いているなら、あなたはそれを読まなければなりません;私は単に主題分野のより一般的な見方を見ていません。 読書後の頭の中の世界の完全な写真が提供されます。 次に進むべき場所を理解すると、さらに明確になります。
プロジェクトを管理している、または技術の専門家である場合は、一般的なプロジェクト活動と多くの共通点があるため、それを読むことを強くお勧めします。 とにかく、SMは基本的な領域であるため、多くのボトルネック、ボトルネックが発生するため、それらを克服するには、どちらにアプローチするかを知る必要があります。 そのため、Habrのブログ「プロジェクト管理」に投稿されました。
一般的に、あなたは正しい本を取る必要があります。 アマゾンに入りました 。
All Articles