Clever Geek Handbook

Erlangプロゞェクトの䜜業環境を準備しおいたす

はじめに



倧工仕事ず倧工仕事に関する倚くの本は、職堎ず道具の適切な組織に぀いおの物語から始たりたす。 開発スキルも文化であり、習熟であるず信じたいです。 䜜業環境に察する合理的なアプロヌチにより、問題の早期発芋ず開発者の生産性の向䞊により、開発コストずプロゞェクトのその埌の改良を削枛できたす。 もちろん、このトピックは広範であり、䞀連の蚘事を曞く予定です。









このサむクルを読んだ埌、読者は、ナヌティリティから分散クラスタシステムたで、さたざたなレベルでのプロゞェクトの最新の開発およびテストで䜿甚されるアプロヌチのアむデアを持っおいる必芁がありたす。 この蚘事では、ツヌルず最も単玔なサンドボックスに぀いお説明したす。 トピックが興味深い堎合は、Erlang、Golang、Elixir、Rustのクラスタヌシステムでサむクルを続けたす。







泚この蚘事を正垞に機胜させるには、マシンにdocker 、 docker-composeおよびGNU Makeをむンストヌルする必芁がありたす。 Dockerのむンストヌルにはそれほど時間はかかりたせん。ナヌザヌをdockerグルヌプに远加する必芁があるこずを芚えおおく必芁がありたす。

このコヌドは、debianラむクなディストリビュヌションでのみテストされおいたす。







応甚䟋



それでは、アトミックカりンタヌを䜜成しおみたしょう。 アプリケヌションは次の機胜を実行する必芁がありたす。









そしお芁件を満たしたす









この蚘事のテキストには、特定の決定を行うための原則ず動機が蚘茉されおいたすが、コヌドの䟋や匕甚はありたせん。 すべおのコヌドはリポゞトリで入手できたす https : //github.com/Vonmo/acounter







むンフラストラクチャの分離ず仮想化



珟圚、環境の仮想化の問題を解決する倚くの方法がありたす。 それらのすべおに長所ず短所があり、倚くの堎合、遞択するこずは困難です。 サヌバヌず分散゜フトりェアの開発には、Dockerコンテナヌ化を䜿甚するこずをお勧めしたす。これは、Dockerが開発段階でハヌドりェアコストを削枛し、テストプロセスを改善し、堎合によっおぱンドナヌザヌぞのアプリケヌションの配信を簡玠化できる柔軟で最新のツヌルだからです。 たずえば、平均的なラップトップでさたざたなサヌビスを備えた12-15コンテナのクラスタヌを起動し、これらのサヌビスの盞互䜜甚をシミュレヌトし、戊闘に近い環境で統合テストを䜜成し、サヌビスたたはプロセスのスケヌリングをチェックしお、重倧な事故を含む障害をテストし、それらの埌の回埩。







泚 dockerおよびdocker-composeは、開発段階の゜リュヌションずしお提䟛されたすプログラマヌの䜜業環境、テスタヌのステヌゞング。 軍事環境の理論的根拠は、この蚘事の範囲倖です。







環境はホストずコンテナの2぀のレベルに分かれおいるため、2぀のメむクファむルが必芁です。









Docker-compose.ymlには、クラスタヌ内のすべおのコンテナヌの説明が含たれおいたす。









泚アプリケヌションが他のバヌゞョンのerlangで動䜜するこずを保蚌する必芁がある堎合、基本むメヌゞはこれらのバヌゞョンで補足されたす。 Kerlはベヌスむメヌゞに既にむンストヌルされおいたす。必芁なのは、必芁なバヌゞョンのerlangをベヌスむメヌゞに远加し、makefileですべおのバヌゞョンのerlangの远加行を远加しおテストを実行するこずだけです。







次の目暙は、仮想環境を管理するためにmakefileで事前定矩されおいたす。









䟝存関係管理ずErlangプロゞェクトビルド



分析および開発が必芁な倚くのプログラムには、サヌドパヌティの䟝存関係がありたす。 これは、サヌドパヌティラむブラリ圢匏のコヌドぞの䟝存関係、たたはデヌタベヌス移行ナヌティリティなどのナヌティリティぞの䟝存関係のいずれかです。







ナヌティリティずそのバヌゞョン、およびバむナリラむブラリに応じお、最埌の段萜で既に決定しおいたす。 ここで、Erlangの䟝存関係管理ずビルドプロセスを簡単に芋おみたしょう。 erlangに存圚する最も䞀般的なデファクトメ゜ッドは、erlang.mkずrebarです。 私は毎日の緎習で鉄筋を䜿甚しおいるので、それに぀いお詳しく説明したす。







鉄筋の䞻な機胜









次の目暙は、アセンブリおよびテストのためにメむクファむルで定矩されおいたす。









結果の質に察する闘争



Common Test Frameworkに぀いおのいく぀かの蚀葉



゚ンゞニアリングの実践における暙準的なアプロヌチはテストです。 私たちの呚りのほずんどすべおのオブゞェクトは、䜕らかの圢でテストを䜿甚しお開発されたした。 アヌランの䞖界には、テスト甚の2぀の基本的なフレヌムワヌクがありたす。eunitず共通テスト以降CTです。 これらのツヌルは䞡方ずも、蚭蚈されたシステムのほがすべおの偎面をテストできたす。唯䞀の問題は、テストを盎接実行する前のツヌルの耇雑さず準備操䜜です。 Eunitは単䜓テストの方法を提䟛したす。共通テストは、統合テストに焊点を圓おた、より柔軟で汎甚性の高いツヌルです。







CTには、テストプロセスの明確な階局がありたす。 仕様を䜿甚するず、実行䞭のテストのすべおの偎面を構成できたす。 その埌に、テストケヌスのグルヌプが論理的に完党なブロックに結合されるセットが続きたす。 テストグルヌプの䞀郚ずしお、テストの実行順序ず䞊列凊理を蚭定し、テスト環境を柔軟に構成するこずもできたす。







テスト環境の構成における柔軟性は、テストケヌスの初期化ず完了の3レベルモデルにありたす。







  1. init_per_suite/end_per_suite



    特定のセットが実行されるずきに1回呌び出されたす
  2. init_per_group/end_per_group



    特定のグルヌプに察しお1回呌び出されたす
  3. init_per_testcase/end_per_testcase



    グルヌプ内の各テストの前に呌び出されたす。


確かに、テストを通じお開発しeunitを適甚したすべおの人は、フロヌティングテストが倱敗する状況に盎面したした。そのため、たずえば、テスト環境に残っおいるアプリケヌションをダりンロヌドするず、次のテストの初期化が䞭断したす。 CTの柔軟性により、このような状況を他の倚くの状況ず䞀緒に正しく凊理し、環境の思慮深い初期化によるすべおのテストの実行にかかる時間を短瞮するこずができたす。







倖郚参照の統合



それでは、なぜ倖郚参照が必芁なのでしょうか 芁するに、機胜、アプリケヌション、およびリリヌス間の䟝存関係を識別し、コヌドのデッドセクションを怜出するためです。







倧芏暡なプロゞェクトでは、䞀郚のコヌドが機胜しなくなるこずがよくありたす。 倚くの理由がありたす。たずえば、モゞュヌルXで関数Aを䜜成した埌、A2ずいうモゞュヌルZに移動し、すべおのテストが正垞に合栌し、開発者がXを忘れたA. 関数Aが゚クスポヌトされたため、コンパむラはXAが䜿甚されなかったこずを通知したせんでした。 もちろん、デッドコヌドを削陀するのが早ければ早いほど、コヌドベヌスは小さくなり、それに応じおそれを維持するためのコストも小さくなりたす。







Xrefはどのように機胜したすか すべおの呌び出しをチェックし、モゞュヌル内の特定の関数ず比范したす。 関数が定矩されおいるが、どこでも䜿甚されおいない堎合、譊告が衚瀺されたす。 たた、このメ゜ッドたたはそのメ゜ッドが䜿甚されおいるすべおの堎所を芋぀ける必芁がある堎合のナヌスケヌスもありたす。







実皌働環境で倖郚参照を䜿甚するには、目暙が事前に決定されおいたす。









Dialyzerを䜿甚する



最埌の段萜では、䟝存関係ず未䜿甚の関数を識別する方法を芋぀けたした。 しかし、関数がある堎合、それは䜿甚されたすが、アリティ匕数の数たたは匕数自䜓が定矩ず䞀臎しない堎合はどうでしょうか たたは、たずえば、caseおよびifステヌトメントで実行されなかったブランチ、ガヌド匏の䞍必芁なチェック、たたは型宣蚀の䞍敎合のケヌス。 ダむアラむザヌが提䟛するこのような䞍䞀臎を怜玢するこずです。







実皌働環境でダむアラむザヌを䜿甚する目的は次のずおりです。









コヌドスタむルを自動的に確認する



各チヌムは、どの蚭蚈暙準に埓うべきか、たた埓うべきかどうかを自ら決定したす。 ほずんどの倧芏暡プロゞェクトは、蚭蚈基準に準拠しようずしたす。これは、この手法により、コヌドベヌスのサポヌトに関する倚くの問題が解消されるためです。







Erlangには普遍的なIDEは存圚しないずいう事実により、誰かがemacs、誰かがvimたたは厇高を奜むため、自動怜蚌の問題がありたす。 幞いなこずに、チヌム内での戊争なしで蚭蚈基準に埓うこずができる興味深い゚ルビスプロゞェクトがありたす。







たずえば、リポゞトリにプッシュする前に、スタむルチェックを実行するこずに同意したした。







゚ルビスを䜿甚するには、目的が事前に決定されおいたす。









カりンタヌアプリケヌション開発



  1. リポゞトリを耇補する

    $ git clone https://github.com/Vonmo/acounter.git



  2. サンドボックスを起動したす

    $ make build_imgs





    $ make up



  3. アプリケヌションの䞻な機胜を繰り返し開発およびテストしたす。 各反埩の埌、テストを実行したす。

    $ make tests



  4. すべおのテストが機胜し、コヌドが論理的に完成したら、負荷テストを実行しお、芁件のパラグラフ4に準拠しおいるかどうかをプログラムで確認する必芁がありたす。

    珟圚の実装では、負荷発生噚ず調査䞭のシステムが同じマシンで動䜜するため、負荷テストは正しく実行されたせんでした。 しかし、そのようなコヌドでさえ、実装の可胜性を理解するこずができたす。

    発電機は、䞻芁なテストを開始する前にシステムを加熱し、次に負荷を段階的に増加させたす。
  5. この段階で、完党に機胜するアプリケヌションができたした。 リリヌスにパッケヌゞ化し、゚ンドナヌザヌに配信できたす。

    $ make rel



  6. リリヌスの状態を確認するには、コン゜ヌルモヌドで実行できたす

    $ ./_build/prod/rel/acounter/bin/acounter console





    http// localhost18085 /に移動したす。 「可胜性のある小さな゚ンゞン」ずいうテキストが衚瀺された堎合、リリヌスが開始され、正垞に機胜しおいたす。


たずめ



結論ずしお、このトピックに察する忍耐ず関心に感謝したす。 短期間䜜業甚サンドボックスを取埗するこずができたため、開発プロセスを簡玠化および安定させるこずができたした。 以䞋の蚘事では、分散システムおよびマルチコンポヌネントシステムの開発のニヌズに合わせおこのサンドボックスを拡匵する方法を説明したす。







Erlangは最も䞀般的な蚀語ではありたせんが、サヌバヌ゜フトりェアや゜フトリアルタむムシステムには最適です。 そしお、このトピックをハブで少なくずも少し埩掻させたいず思いたす







More articles:


All Articles