翻訳この記事は、以下のシリーズの2つ目の記事です。Microsoft(前の記事はこちら)では、これらの対策に何をしたかをお話しましょう。我々は、エンジニアリングの行動原則を設定・適用しました。これらは全く誰にとって目新しいものではありませんが、先ほど紹介した問題と相関関係にあります。我々は、テスト環境を追加しました。そこではバージョンコントロールと本番環境への適用に対する承認行為を採用しました。Ansibleの環境について環境について話しましょう。2年半前に、我々はAnsibleTowerを導入しました。我々は開発/テスト、プリプロダクション、プロダクションの3つの環境を用意しました。これら3つの環境にはそれぞれ特定の目的がありそれらの目的の達成が強制されています。開発/テスト環境においては、過去の環境と同じものが構成されています。環境へのフルな権限は与えていません。テストラボの中の端末にしかアクセス・実行できず、それらは仮想環境でネットワークを再現しています。ネットワーク全体を再現してテストしたいというリクエストでも、他の人たちを待たせることなくテスト実行するための環境を渡すことができます。Developper)』へのコンバートへトライできることです。プラットフォームへもログインできますし、テストでラボ全体を使ってテストをして環境を壊すようなコードを書くことができますし、誰かがそれを修正することもできますし、やろうと思えばどんな事にもトライできます。プリプロダクション環境をみてみましょう。私たちは完全なネットワークアクセスを持っていますが、開発とマスターのブランチアクセスのみに限定されています。作成したコードは開発(develop)ブランチに入るためにどのようにプロダクションへの移行を進めるかについて会話を始めたなら、完全なコードレビューを経る必要があり、レビューを経た時点でコードはプロダクション用途として完全なものと考えられます。プロダクション環境のクラスタです。最高規模のクラスタで、最も多くのCPU数やメモリを持ち、ここですべてのプロダクションワークロードを実行し、高可用性を確実にするため監視もされているクラスタです。これらに対する更新作業の裏側ではほとんどがAnsibleTowerを用いて行われています。Towerが可能にすることの一つに、バージョンコントロールがあります。以前は、必ずCLIを用いてそれぞれの環境でコマンド実行の必要性がありました。他の誰かが知らないうちにログインし、コマンドのたった一つに私が知らない変更を加えて、結果私が実行した時に予期せぬ結果を生み出すようなことが多々ありました。Enterpriseを用いています。MicrosoftがGitHubエンタープライズのヘビーユーザーだったのでGitHubを買ったという話がジョークだったと言いたいのですが、冗談ではなかったのでしょう。実際に我々はGitHubエンタープライズを使い始めました。私たちはコードをすべてのサーバーに配布し、そしてそれらがきちんと特定のブランチから配布されているかを検証し確認します。これらを原則とし、ブランチルールなどの規則を適用することができるようになりました。最終的には、プロダクション環境へのワークフローを承認します。コードは開発ブランチから分岐したFeatureブランチから始まって、エンジニアたちは本当に様々な面白いコードを多数作成して、それらの開発中コードを繰り返しデバイスに対して実行して、本当に動くかを確実にテストしています。問題なく動作できた場合には、開発ブランチへのプルリクを実行します。実際にコードがレビューされ、プロダクションレディかどうかを確認します。こんな形なので、おそらく誰でも機能開発のコード開発にトライすることができると思っています。現在では素晴らしいことに、2週に一度、変更があった全てのコードをマスターに適用するような変更を加えることができるようになりました。組織にいる誰もが自動化に対して取り組めるようになっているし、自動化のコードを書いた全ての人を褒め称えるような組織的なコミュニケーションもやっています。これが本当に組織文化の変革における始まりだったのです。古いシステムで私が自動化のコードを何か新しいものを書いたとして、話したこともないような人がそのコードを信用してくれて、プロダクション環境で実行しようとしてくれるようなことがあると思いますか?それがどう動作するかもわからないのに?今、Microsoftは文化を作り上げました。そこでは自動化の新機能をリリースするために協力したとして皆が名前をクレジットしたいと考えるようになったので、新たなCoolな取り組みにどんどんと参加するようになっています。Towerを購入しインストールすることにしました。Towerを置いたのです。(2)めりーくりすます。Hatのさいとうです。オブジェクト管理に関して皆さんこんにちは、ソリューションアーキテクトの岡野です。Scali...この記事は、以下のシリーズの4つ目の記事です。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。