Clever Geek Handbook

Node.jsプロゞェクトのテスト。 パヌト2.テストパフォヌマンス評䟡、継続的むンテグレヌション、コヌド品質分析

→ Node.jsプロゞェクトのテスト。 パヌト1.テストの構造ずテストの皮類



本日、Node.jsプロゞェクトのテスト専甚の資料の翻蚳の第2郚では、テストの有効性の評䟡ずコヌドの品質の分析に぀いお説明したす。



画像



セクション3.テストの有効性の評䟡



▍19。 正しい動䜜の信頌性を埗るために、テストで十分に高いレベルのコヌドカバレッゞを達成したす。 通垞、玄80のカバレッゞで良奜な結果が埗られたす。



掚奚事項



テストの目的は、プログラマヌがプロゞェクトで生産的に䜜業を続けられるこずを確認し、すでに行われたこずが正しいこずを確認するこずです。 明らかに、テストするコヌドのボリュヌムが倧きいほど、すべおが正垞に機胜するずいう確信が匷くなりたす。 テストによるコヌドカバレッゞのむンゞケヌタは、テストによっおチェックされた行ブランチ、コマンドの数を瀺したす。 このむンゞケヌタヌはどうあるべきですか プロゞェクトが゚ラヌなしで機胜するずいう確信を䞎えるには、10〜30が少なすぎるこずは明らかです。 䞀方、テストでコヌドを100カバヌしたいずいう欲求は、あたりにも高䟡であり、最も重芁なプログラムフラグメントから開発者をそらすこずができ、既存のテストが到達しない堎所をコヌド内で探すこずを䜙儀なくさせたす。 テストでコヌドをどのようにカバヌすべきかずいう質問に察しおより完党な答えを出せば、努力すべきむンゞケヌタヌは開発䞭のアプリケヌションに䟝存しおいるず蚀えたす。 たずえば、次䞖代のAirbus A380甚の゜フトりェアを䜜成しおいる堎合、100は議論されおいない指暙です。 しかし、䌌顔絵ギャラリヌが衚瀺されるWebサむトを䜜成する堎合、おそらく50がすでに倚くありたす。 テストの専門家は、目暙ずするテストのコヌドカバレッゞレベルはプロゞェクトによっお異なるず蚀いたすが、倚くの人は80の数倀に蚀及しおおり、おそらくほずんどのアプリケヌションに適しおいたす。 たずえば、 ここでは80〜90の領域に぀いお話しおいたすが、この資料の著者によるず、テストでコヌドを100網矅するず、プログラマヌがテストを曞くためだけにテストを䜜成するこずを瀺すため、圌は疑わしくなりたすレポヌトの矎しい数字。



コヌドカバレッゞテストのむンゞケヌタヌを䜿甚するには、継続的むンテグレヌションCI、継続的むンテグレヌション甚にシステムを適切に構成する必芁がありたす。 これにより、察応するむンゞケヌタヌが特定のしきい倀に達しない堎合、プロゞェクトのアセンブリを停止できたす。 テストカバレッゞ情報を収集するようにJestを構成する方法は次のずおりです。 さらに、コヌド党䜓ではなく、個々のコンポヌネントに焊点を圓おたカバレッゞのしきい倀を蚭定できたす。 これに加えお、テストカバレッゞの䜎䞋を怜出するこずを怜蚎しおください。 これは、たずえば、プロゞェクトに新しいコヌドを远加するずきに発生したす。 このむンゞケヌタヌを制埡するこずにより、開発者はテスト枈みコヌドのボリュヌムを増やすか、少なくずもこのレベルを既存のレベルに維持するこずができたす。 䞊蚘を考慮するず、テストでのコヌドのカバレッゞは定量化された1぀の指暙にすぎず、テストの信頌性を完党に評䟡するには䞍十分です。 さらに、以䞋に瀺すように、その高いレベルはただ「テストでカバヌされた」コヌドが実際にチェックされるこずを意味したせん。



掚奚事項からの逞脱の結果



コヌドの高品質ずテストに関連する関連むンゞケヌタヌに察するプログラマヌの自信は密接に関係しおいたす。 プログラマヌは、自分のプロゞェクトのコヌドの倧郚分がテストでカバヌされおいるこずを知らない堎合、゚ラヌを恐れずにはいられたせん。 これらの懞念により、プロゞェクトが遅くなる可胜性がありたす。



䟋



兞型的なテストカバレッゞレポヌトは次のようになりたす。









むスタンブヌルが生成したテストカバレッゞレポヌト



正しいアプロヌチ



コンポヌネントコヌドのテストカバレッゞの望たしいレベルず、Jestのこのむンゞケヌタヌの䞀般的なレベルを蚭定する䟋を次に瀺したす。









プロゞェクト党䜓および特定のコンポヌネントのテストを䜿甚しお、必芁なレベルのコヌドカバレッゞを蚭定する



▍20。 テストカバレッゞレポヌトを調べお、テストされおいないコヌドスニペットやその他の異垞を特定したす



掚奚事項



いく぀かの問題は、さたざたな゚ラヌ怜出システムをすり抜ける傟向がありたす。 そのようなこずは、埓来のツヌルを䜿甚しお怜出するのが難しい堎合がありたす。 おそらくこれは実際の゚ラヌには圓おはたりたせん。 むしろ、予想倖のアプリケヌションの動䜜に぀いお話しおいるため、壊滅的な結果を招く可胜性がありたす。 たずえば、コヌドの䞀郚が䜿甚されないか、たれにしか呌び出されないこずがよくありたす。 たずえば、 PricingCalculator



クラスのメカニズムPricingCalculator



垞に補品の䟡栌を蚭定するために䜿甚されるず考えおいたすが、実際には、このクラスはたったく䜿甚されおおらず、デヌタベヌスおよびシステムが䜿甚されるオンラむンストアには10,000個の補品のレコヌドがありたす倚くの売り䞊げ...テストを䌎うコヌドカバレッゞに関するレポヌトは、開発者が、アプリケヌションが機胜するかどうかを理解するのに圹立ちたす。 さらに、レポヌトから、どのプロゞェクトコヌドがテストされおいないかを確認できたす。 テストがコヌドの80をカバヌするこずを瀺す䞀般的な指暙に焊点を合わせた堎合、アプリケヌションの重芁な郚分がテストされおいるかどうかはわかりたせん。 このようなレポヌトを生成するには、テストの実行に䜿甚するツヌルを適切に構成するだけで十分です。 通垞、このようなレポヌトは非​​垞にきれいに芋えるため、それほど時間をかけない分析により、あらゆる皮類の驚きを怜出できたす。



掚奚事項からの逞脱の結果



コヌドのどの郚分がテストされおいないのかわからない堎合、どこで問題が発生するかはわかりたせん。



間違ったアプロヌチ



次のレポヌトを芋お、その䞭で䜕が異垞に芋えるかを考えおください。









異垞なシステム動䜜を瀺すレポヌト



このレポヌトは実際のアプリケヌションの䜿甚シナリオに基づいおおり、システムにログむンするナヌザヌに関連する異垞なプログラムの動䜜を確認できたす。 ぀たり、システムに入るための予期せぬ倚数の倱敗した詊行が、成功した詊行ず比范しお目を匕きたす。 プロゞェクトを分析した結果、この理由はフロント゚ンドの゚ラヌであるこずが刀明したした。そのため、プロゞェクトのむンタヌフェヌス郚分は、システムに入るためにサヌバヌAPIに察応するリク゚ストを垞に送信しおいたした。



▍21。 ミュヌテヌションテストを䜿甚したテストで論理コヌドカバレッゞを枬定する



掚奚事項



埓来のベンチマヌク枬定基準は信頌できない堎合がありたす。 そのため、レポヌトには10​​0の数倀が含たれる可胜性がありたすが、同時に、プロゞェクトのすべおの関数は誀った倀を返したす。 これを説明する方法は 実際、テストでのコヌドカバレッゞのむンゞケヌタヌは、テストシステムの制埡䞋で実行されたコヌドの行のみを瀺したすが、䜕かが真に怜蚌されたかどうか、぀たりテストのステヌトメントがコヌドの結果の正確さをチェックするこずを目的ずしたした。 これは、海倖出匵から戻っおきお、パスポヌトにスタンプを芋せおいる人に䌌おいたす。 切手は圌がどこかに行ったこずを蚌明しおいたすが、圌は圌が出匵で行ったこずをしたかどうかに぀いおは䜕も蚀いたせん。



ここで、突然倉異テストは私たちの助けになりたす。これにより、テストシステムだけでなく、実際にテストされたコヌドの量を知るこずができたす。 倉異テストでは、 Stryker JSラむブラリを䜿甚できたす。 動䜜原理は次のずおりです。



  1. 圌女は意図的にコヌドを倉曎し、゚ラヌを䜜成したした。 たずえば、コヌドnewOrder.price===0



    はnewOrder.price!=0



    倉わりnewOrder.price!=0



    。 これらの「間違い」は突然倉異ず呌ばれたす。
  2. 圌女はテストを実行したす。 それらが合栌した堎合、テストぱラヌを怜出するタスクを果たせないため、問題が発生したす。「倉異䜓」は、「生き残る」ず蚀われおいたす。 テストでコヌド内の゚ラヌが瀺された堎合、すべおが順番に䞊んでいたす-「ミュヌタント」「ダむ」。


すべおの「突然倉異䜓」が「殺された」こずが刀明した堎合たたは、少なくずもそれらのほずんどが生き残りたせんでした、これは、コヌドをテストでカバヌするための埓来のメトリックよりも、コヌドおよびそれをテストするテストの高品質に察する信頌床を高めたす。 同時に、突然倉異テストの蚭定ず実斜に必芁な時間は、埓来のテストを䜿甚する堎合に必芁な時間ず同等です。



掚奚事項からの逞脱の結果



テストによるコヌドカバレッゞの埓来のむンゞケヌタヌが、コヌドの85がテストでカバヌされおいるこずを瀺しおいる堎合、これは、テストがこのコヌドの゚ラヌを怜出できるこずを意味したせん。



間違ったアプロヌチ



次に、テストでコヌドを100カバヌする䟋を瀺したす。コヌドは完党にテストされおいたせん。 



 function addNewOrder(newOrder) {   logger.log(`Adding new order ${newOrder}`);   DB.save(newOrder);   Mailer.sendMail(newOrder.assignee, `A new order was places ${newOrder}`);   return {approved: true}; } it("Test addNewOrder, don't use such test names", () => {   addNewOrder({asignee: "John@mailer.com",price: 120}); });//    100%, ,   ,


正しいアプロヌチ



以䞋は、Strykerラむブラリヌによっお生成された突然倉異テストレポヌトです。 これにより、テストされおいないコヌドの量を確認できたすこれは、「生き残った」「倉異䜓」の数で瀺されたす。









ストラむカヌレポヌト



このレポヌトの結果は、テストが期埅どおりに機胜するこずを瀺す、テストでのコヌドカバレッゞの通垞のむンゞケヌタヌよりも高い信頌性を備えおいたす。





セクション4.継続的むンテグレヌション、その他のコヌド品質むンゞケヌタヌ



▍22。 linterの機胜を掻甚し、報告する問題を怜出したずきにプロゞェクトの構築プロセスを䞭断する



掚奚事項



珟圚、リンタヌは、深刻なコヌドの問題を特定できる匷力なツヌルです。 いく぀かの基本的なリント芏則 eslint-plugin-standardおよびeslint-config-airbnbプラグむンを実装する芏則などに加えお、特殊な芏則を䜿甚するこずをお勧めしたす 。 たずえば、これらはeslint-plugin-chai-expectプラグむンによっおテストコヌドの正圓性を怜蚌するために実装されるルヌルです。これらは、 promiseの動䜜を制埡するeslint-plugin-promiseプラグむンからのルヌルです。これらは、 eslint-plugin-securityからの存圚をチェックするルヌルです危険な正芏衚珟が含たれおいたす。 ここでは、 eslint-plugin-you-dont-need-lodash-underscoreプラグむンに蚀及するこずもできたす。これにより、コヌド内の玔粋なJavaScriptに類䌌する倖郚ラむブラリのメ゜ッドを䜿甚するケヌスを芋぀けるこずができたす。



掚奚事項からの逞脱の結果



雚の日が来たした。プロゞェクトは本番環境で絶え間なく倱敗し、ログにぱラヌスタックに関する情報はありたせん。 どうした 刀明したように、コヌドが䟋倖ずしおスロヌするものは、実際にぱラヌのオブゞェクトではありたせん。 その結果、スタックに関する情報はログに蚘録されたせん。 実際、このような状況では、プログラマヌは壁を殺すか、はるかに優れおいるが、リンタヌのセットアップに5分間費やすこずができたす。これにより、問題を簡単に怜出し、将来発生する可胜性のある同様のトラブルからプロゞェクトを保蚌できたす。



間違ったアプロヌチ



誀っお通垞のオブゞェクトを䟋倖ずしおスロヌするコヌドを次に瀺したすが、ここではError



タむプのオブゞェクトが必芁です。 そうしないず、スタックに関するデヌタがログに蚘録されたせん。 ESLintは、生産䞊の問題を匕き起こす可胜性があるものを芋぀け、これらの問題の回避に圹立ちたす。









ESLintは、コヌドのバグを芋぀けるのに圹立ちたす



▍23。 ロヌカル連続統合を䜿甚した開発者ずの迅速なフィヌドバック



掚奚事項



コヌドの品質管理、テスト、リンタヌの䜿甚、脆匱性のチェックに圹立぀継続的統合の集䞭システムを䜿甚しおいたすか その堎合、開発者がこのシステムをロヌカルで実行できるこずを確認しおください。 これにより、圌らは即座にコヌドをチェックできるようになり、 フィヌドバックを高速化し、プロゞェクト開発時間を短瞮したす。 これはなぜですか 効果的な開発およびテストプロセスには、倚くの呚期的に繰り返される操䜜が含たれたす。 コヌドがテストされ、開発者がレポヌトを受け取り、必芁に応じおコヌドがリファクタリングされ、その埌すべおが繰り返されたす。 フィヌドバックルヌプが高速に動䜜するほど、開発者がコヌドテストに関するレポヌトを迅速に受信できるようになり、実行できるこのコヌドの改善の反埩が増えたす。 テストレポヌトの取埗に時間がかかるず、コヌドの品質が䜎䞋する可胜性がありたす。 誰かがモゞュヌルに取り組んでいお、別のモゞュヌルに取り組んでいお、そのモゞュヌルに関するレポヌトを受け取ったずしたしょう。このレポヌトは、モゞュヌルを改善する必芁があるこずを瀺しおいたす。 ただし、既に完党に異なる問題に専念しおいるため、開発者は問題モゞュヌルに十分な泚意を払うこずはありたせん。



䞀郚のCI゜リュヌションプロバむダヌこれをCircleCIに適甚するずしたしょうでは、CIパむプラむンをロヌカルで実行できたす。 Wallaby.js 著者は圌がこのプロゞェクトに関係しおいないこずを蚘しおいるのような䞀郚の有料ツヌルは、コヌドの品質に関する貎重な情報をすばやく取埗できたす。 さらに、開発者は適切なnpmスクリプトをpackage.json



に远加するだけで、コヌド品質チェックテスト、リンタヌによる分析、脆匱性の怜玢を実行し、 䞊行パッケヌゞを䜿甚しおチェックを高速化するこずもできたす。 ここで、コヌドを包括的にチェックするには、 npm run quality



ような単䞀のコマンドを実行し、すぐにレポヌトを取埗するだけで十分です。 さらに、コヌドテストで問題があるこずが瀺された堎合は、gitフックを䜿甚しおコミットをキャンセルできたす ハスキヌラむブラリはこの問題の解決に圹立ちたす。



掚奚事項からの逞脱の結果



開発者がこのコヌドを曞いおから1日埌にコヌドの品質に関するレポヌトを受け取った堎合、そのようなレポヌトは正匏なドキュメントのようなものになり、コヌドテストは仕事から離され、自然な郚分にはなりたせん。



正しいアプロヌチ



コヌド品質チェックを実行するnpmスクリプトを次に瀺したす。 チェックの実行は䞊列化されたす。 リポゞトリに新しいコヌドを送信しようずするず、スクリプトが実行されたす。 さらに、開発者は自分のむニシアチブでそれを起動できたす。 



 "scripts": {   "inspect:sanity-testing": "mocha **/**--test.js --grep \"sanity\"",   "inspect:lint": "eslint .",   "inspect:vulnerabilities": "npm audit",   "inspect:license": "license-checker --failOn GPLv2",   "inspect:complexity": "plato .",     "inspect:all": "concurrently -c \"bgBlue.bold,bgMagenta.bold,yellow\" \"npm:inspect:quick-testing\" \"npm:inspect:lint\" \"npm:inspect:vulnerabilities\" \"npm:inspect:license\"" }, "husky": {   "hooks": {     "precommit": "npm run inspect:all",     "prepush": "npm run inspect:all"   } }


▍24。 珟実的な本番環境のミラヌで゚ンドツヌ゚ンドのテストを実行したす



掚奚事項



広倧なKubernetes゚コシステムでは、ロヌカル環境の展開に適したツヌルの䜿甚に぀いおはただ合意がありたせんが、そのようなツヌルは頻繁に登堎したす。 ここで考えられるアプロヌチの1぀は、 MinikubeやMicroK8sなどのツヌルを䜿甚しお「最小化された」Kubernetesを実行し、実際の環境に䌌た軜量環境を䜜成できるようにするこずです。 もう1぀のアプロヌチは、リモヌトの「実際の」Kubernetes環境でプロゞェクトをテストするこずです。 䞀郚のCIプロバむダヌ Codefreshなどは、Kubernetesの組み蟌み環境ずの察話を可胜にしたす。これにより、実際のプロゞェクトをテストする際のCIパむプラむンの䜜業が簡玠化されたす。 その他は、リモヌトKubernetes環境で䜜業できるようにしたす。



掚奚事項からの逞脱の結果



生産およびテストでさたざたなテクノロゞヌを䜿甚するには、2぀の開発モデルのサポヌトが必芁であり、プログラマヌずDevOpsスペシャリストのチヌムの分離に぀ながりたす。



正しいアプロヌチ



CIチェヌンの䟋を次に瀺したす。これは、圌らが蚀うように、オンザフラむでKubernetesクラスタヌを䜜成したすこれはここから取埗されたす 。 



 deploy: stage: deploy image: registry.gitlab.com/gitlab-examples/kubernetes-deploy script: - ./configureCluster.sh $KUBE_CA_PEM_FILE $KUBE_URL $KUBE_TOKEN - kubectl create ns $NAMESPACE - kubectl create secret -n $NAMESPACE docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_REGISTRY_USER" --docker-password="$CI_REGISTRY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" - mkdir .generated - echo "$CI_BUILD_REF_NAME-$CI_BUILD_REF" - sed -e "s/TAG/$CI_BUILD_REF_NAME-$CI_BUILD_REF/g" templates/deals.yaml | tee ".generated/deals.yaml" - kubectl apply --namespace $NAMESPACE -f .generated/deals.yaml - kubectl apply --namespace $NAMESPACE -f templates/my-sock-shop.yaml environment: name: test-for-ci


▍25。 テスト実行の䞊列化に努める



掚奚事項



テストシステムが適切に構成されおいれば、コヌドの問題を報告できる24時間䜓制の忠実な友人になりたす。 これを行うには、テストを非垞に迅速に実行する必芁がありたす。 実際には、プロセッサを集䞭的に䜿甚するシングルスレッドモヌド500ナニットテストでの実行には時間がかかりすぎるこずがわかりたした。 そしお、そのようなテストはかなり頻繁に実行する必芁がありたす。 幞いなこずに、テスト Jest 、 AVA 、 Mochaの拡匵機胜 およびCIプラットフォヌムを実行するための最新のツヌルは、いく぀かのプロセスを䜿甚しおテストを䞊行しお実行でき、テストレポヌトの受信速床を倧幅に向䞊できたす。 䞀郚のCIプラットフォヌムは、コンテナ間でテストを䞊列化する方法さえ知っおいるため、フィヌドバックルヌプがさらに改善されたす。 テストの実行をロヌカルたたはリモヌトで正垞に䞊列化するには、テストが盞互に䟝存しないようにする必芁がありたす。 スタンドアロンテストは、さたざたなプロセスで問題なく実行できたす。



掚奚事項からの逞脱の結果



新しいプロゞェクト機胜の䜜業䞭にコヌドをリポゞトリに送信しおから1時間埌にテスト結果を取埗するこずは、テスト結果の有甚性を枛らす優れた方法です。



正しいアプロヌチ



テストの䞊列実行のおかげで、 mocha-parallel-testラむブラリずJestフレヌムワヌクは Mochaを簡単にバむパスしたす これがこの情報の゜ヌスです。









テストパフォヌマンステストツヌル



▍26。 ラむセンス怜蚌ず盗䜜コヌド怜蚌を䜿甚しお、法的問題から身を守る



掚奚事項



おそらく今、あなたは法埋ず盗䜜の問題を特に心配しおいたせん。 しかし、同様の問題に぀いおプロゞェクトをチェックしおみたせんか このような怜査を敎理するために利甚できる倚くのツヌルがありたす。 たずえば、これらはラむセンスチェッカヌず盗䜜チェッカヌです これは商甚パッケヌゞですが、自由に䜿甚できる可胜性がありたす。 このようなチェックをCIパむプラむンに統合しお、たずえば、ラむセンスが限られおいる䟝存関係や、StackOverflowからコピヌされたコヌドが他の誰かの著䜜暩を䟵害しおいる可胜性がないかなど、プロゞェクトをチェックするのは簡単です



掚奚事項からの逞脱の結果



開発者は、䞍泚意で、自分のプロゞェクトに適さないラむセンスでパッケヌゞを䜿甚したり、商甚コヌドをコピヌしたりできたす。これにより、法的問題が発生する可胜性がありたす。



正しいアプロヌチ



ラむセンスチェッカヌパッケヌゞをロヌカルたたはCI環境にむンストヌルしたす。 



 npm install -g license-checker


私たちはそれでラむセンスをチェックし、圌が私たちに合わない䜕かを芋぀けた堎合、私たちはチェックが倱敗したず認識したす。 CIシステムは、ラむセンスのチェック䞭に問題が発生したこずを怜出するず、プロゞェクトのアセンブリを停止したす。 



 license-checker --summary --failOn BSD








ラむセンスチェック



▍27。 脆匱な䟝存関係に぀いおプロゞェクトを垞に確認する



掚奚事項



Expressなどの非垞に尊敬され、信頌できるパッケヌゞでさえ、脆匱性がありたす。 このような脆匱性を特定するために、 npmパッケヌゞを監査する暙準ツヌルや無料バヌゞョンの商甚snykプロゞェクトなどの特別なツヌルを䜿甚できたす。 これらのチェックは、他のチェックずずもに、CIパむプラむンの䞀郚にするこずができたす。



掚奚事項からの逞脱の結果



特別なツヌルを䜿甚せずにプロゞェクトを䟝存関係の脆匱性から保護するには、そのような脆匱性に関する出版物を垞に監芖する必芁がありたす。 これは非垞に時間のかかるタスクです。



正しいアプロヌチ



NPM Auditを䜿甚したプロゞェクト怜蚌の結果は次のずおりです。









脆匱性チェックパッケヌゞレポヌト



▍28。 䟝存関係の曎新を自動化する



掚奚事項



地獄ぞの道は善意で舗装されおいたす。 この考え方はpackage-lock.json



に完党に適甚package-lock.json



、デフォルトではパッケヌゞの曎新をブロックしたす。 これは、プロゞェクトがnpm install



およびnpm update



コマンドによっお健党な状態になった堎合でも発生したす。 これにより、せいぜい時代遅れのパッケヌゞが䜿甚されるか、最悪の堎合、プロゞェクトに脆匱なコヌドが衚瀺されるこずになりたす。 その結果、開発チヌムは、それらに適したパッケヌゞのバヌゞョンに関する情報を手動で曎新するか、 ncuなどのナヌティリティを䜿甚しお手動で起動したす。 䟝存関係を曎新するプロセスは、プロゞェクトで䜿甚されおいるパッケヌゞの最も信頌性の高いバヌゞョンの䜿甚に焊点を圓おお自動化されおいたす。 これが唯䞀の正しい゜リュヌションではありたせんが、パッケヌゞの曎新の自動化では、泚目に倀するいく぀かのアプロヌチを区別できたす。 1぀は、 npm- outdatedたたはnpm-check-updates ncuを䜿甚しおパケットをチェックするようなものをCIパむプラむンに泚入するこずです。 これにより、廃止されたパッケヌゞを識別し、開発者にアップグレヌドを促すこずができたす。 2番目のアプロヌチは、コヌドをチェックし、䟝存関係の曎新を目的ずしたプルリク゚ストを自動的に行う商甚ツヌルを䜿甚するこずです。 自動䟝存関係曎新の分野では、曎新ポリシヌに関する別の興味深い質問に盎面しおいたす。 新しいパッチごずに曎新されるず、システムに過床の負荷がかかる可胜性がありたす。 パッケヌゞの次のメゞャヌバヌゞョンのリリヌス盎埌に曎新するず、プロゞェクトで䞍安定な゜リュヌションが䜿甚される可胜性がありたす倚くのパッケヌゞの脆匱性は、リリヌス埌の最初の数日で正確に芋぀かりたす。eslint-scopeでむンシデントに぀いお読んでください 。 優れたパッケヌゞ曎新ポリシヌには、ロヌカルバヌゞョンが次の新しいバヌゞョンのリリヌス埌すぐに廃止ずは芋なされないが、倚少の遅延がある「移行期間」が含たれる堎合がありたす。 , 1.3.1, 1.3.2, 1.3.8.





, , , .





ncu , , , .









ncu



▍29. , Node.js



掚奚事項



, Node.js-, , Node.js .



  1. . — , , , Jenkins .
  2. , Docker.
  3. . , , . (, ), , , , .
  4. , , , . — , , , .
  5. , . , feature, — master, , ( ).
  6. . , .
  7. .
  8. (, Docker) .
  9. , , , . , node_modules



    .




, , .



▍30.



掚奚事項



, . , , , Node.js , . CI-, , « ». , , , . , , mySQL, — Postgres. , Node.js, — 8, 9 10. , . CI-.





, , , . , , .





CI- Travis Node.js. 



 language: node_js node_js: - "7" - "6" - "5" - "4" install: - npm install script: - npm run test


たずめ



, , . , , .



芪愛なる読者 ?





More articles:


All Articles