Menguji proyek Node.js. Bagian 2. Tes evaluasi kinerja, integrasi berkelanjutan dan analisis kualitas kode

→ Menguji proyek Node.js. Bagian 1. Tes anatomi dan jenis tes

Hari ini, di bagian kedua dari terjemahan materi yang dikhususkan untuk menguji proyek Node.js, kita akan berbicara tentang mengevaluasi efektivitas tes dan menganalisis kualitas kode.

Bagian 3. Evaluasi keefektifan tes

▍19. Mencapai tingkat cakupan kode yang cukup tinggi dengan pengujian untuk mendapatkan kepercayaan dalam operasi yang benar. Biasanya cakupan sekitar 80% memberikan hasil yang baik.

Rekomendasi

Tujuan pengujian adalah untuk memastikan bahwa programmer dapat terus bekerja secara produktif pada proyek, memastikan bahwa apa yang telah dilakukan sudah benar. Jelas, semakin besar volume kode yang diuji, semakin kuat keyakinan bahwa semuanya berfungsi sebagaimana mestinya. Indikator jangkauan kode dengan tes menunjukkan berapa banyak baris (cabang, perintah) diperiksa oleh tes. Apa yang seharusnya indikator ini? Jelas bahwa 10-30% terlalu sedikit untuk memberi keyakinan bahwa proyek akan bekerja tanpa kesalahan. Di sisi lain, keinginan untuk cakupan 100% dari kode dengan tes bisa menjadi terlalu mahal dan dapat mengalihkan pengembang dari fragmen program yang paling penting, memaksanya untuk mencari di kode tempat-tempat yang tidak terjangkau oleh tes yang ada. Jika Anda memberikan jawaban yang lebih lengkap untuk pertanyaan tentang apa yang harus menjadi cakupan kode dengan tes, maka kita dapat mengatakan bahwa indikator yang harus kita perjuangkan tergantung pada aplikasi yang dikembangkan. Misalnya, jika Anda menulis perangkat lunak untuk Airbus A380 generasi berikutnya, maka 100% adalah indikator yang bahkan tidak dibahas. Tetapi jika Anda membuat situs web di mana galeri karikatur akan ditampilkan, maka mungkin 50% sudah banyak. Meskipun ahli pengujian mengatakan bahwa tingkat cakupan kode dengan tes yang harus Anda tuju tergantung pada proyek, banyak dari mereka menyebutkan angka 80%, yang mungkin cocok untuk sebagian besar aplikasi. Sebagai contoh, di sini kita berbicara tentang sesuatu di wilayah 80-90%, dan, menurut penulis materi ini, cakupan 100% dari kode dengan tes membuatnya curiga, karena itu mungkin menunjukkan bahwa programmer menulis tes hanya untuk mendapatkan angka yang indah dalam laporan.

Untuk menggunakan indikator tes cakupan kode, Anda harus mengkonfigurasi sistem Anda dengan benar untuk integrasi berkelanjutan (CI, Integrasi Berkelanjutan). Ini akan memungkinkan, jika indikator yang sesuai tidak mencapai ambang tertentu, untuk menghentikan perakitan proyek. Berikut cara mengkonfigurasi Jest untuk mengumpulkan informasi cakupan tes. Selain itu, Anda dapat mengonfigurasi batas cakupan bukan untuk seluruh kode, tetapi memfokuskan pada komponen individual. Selain itu, pertimbangkan mendeteksi penurunan cakupan tes. Ini terjadi, misalnya, ketika menambahkan kode baru ke proyek. Kontrol indikator ini akan mendorong pengembang untuk meningkatkan volume kode yang diuji, atau setidaknya untuk mempertahankan volume ini pada level yang ada. Dalam pandangan di atas, cakupan kode dengan pengujian hanya satu indikator, terkuantifikasi, yang tidak cukup untuk sepenuhnya mengevaluasi keandalan pengujian. Selain itu, seperti yang akan ditunjukkan di bawah, levelnya yang tinggi belum berarti bahwa kode “ditutupi dengan tes” benar-benar diperiksa.

Konsekuensi Penyimpangan dari Rekomendasi

Keyakinan programmer pada kualitas tinggi kode dan indikator terkait yang terkait dengan pengujian berjalan seiring. Seorang programmer tidak bisa tidak takut akan kesalahan jika dia tidak tahu bahwa sebagian besar kode dalam proyeknya dicakup oleh tes. Kekhawatiran ini dapat memperlambat proyek Anda.

Contoh

Begini seperti apa laporan cakupan pengujian.


Laporan cakupan tes yang dihasilkan oleh Istanbul

Pendekatan yang benar

Berikut adalah contoh pengaturan tingkat cakupan uji yang diinginkan dari kode komponen dan tingkat umum indikator ini di Jest.


Mengatur tingkat cakupan kode yang diinginkan dengan tes untuk seluruh proyek dan untuk komponen tertentu

▍20. Periksa laporan cakupan kode dengan tes untuk mengidentifikasi bagian kode yang tidak terlindungi dan anomali lainnya

Rekomendasi

Beberapa masalah cenderung menyelinap melalui berbagai sistem deteksi kesalahan. Hal-hal seperti itu bisa sulit dideteksi menggunakan alat tradisional. Mungkin ini tidak berlaku untuk kesalahan nyata. Sebaliknya, kita berbicara tentang perilaku aplikasi yang tidak terduga, yang dapat memiliki konsekuensi yang menghancurkan. Misalnya, sering terjadi bahwa beberapa fragmen kode tidak pernah digunakan atau jarang dipanggil. Misalnya, Anda berpikir bahwa mekanisme kelas PricingCalculator selalu digunakan untuk menetapkan harga suatu produk, tetapi ternyata kelas ini tidak digunakan sama sekali, dan ada catatan 10.000 produk dalam database, dan di toko online tempat sistem tersebut digunakan, banyak penjualan ... Laporan tentang cakupan kode dengan tes membantu pengembang memahami jika aplikasi berfungsi sebagaimana mestinya. Selain itu, dari laporan Anda dapat mengetahui kode proyek mana yang tidak diuji. Jika Anda fokus pada indikator umum yang menunjukkan bahwa pengujian mencakup 80% dari kode, Anda tidak dapat mengetahui apakah bagian-bagian penting dari aplikasi sedang diuji. Untuk menghasilkan laporan seperti itu, cukup dengan mengkonfigurasi alat yang Anda gunakan untuk menjalankan tes dengan benar. Laporan seperti itu biasanya terlihat sangat cantik, dan analisisnya, yang tidak memakan banyak waktu, memungkinkan Anda untuk mendeteksi segala macam kejutan.

Konsekuensi Penyimpangan dari Rekomendasi

Jika Anda tidak tahu tentang bagian mana dari kode Anda yang belum diuji, maka Anda tidak tahu di mana Anda bisa mendapatkan masalah.

Pendekatan yang salah

Lihatlah laporan berikutnya dan pikirkan tentang apa yang tampak tidak biasa di dalamnya.


Laporan yang menunjukkan perilaku sistem yang tidak biasa

Laporan ini didasarkan pada skenario penggunaan aplikasi nyata dan memungkinkan Anda untuk melihat perilaku program yang tidak biasa terkait dengan pengguna yang masuk ke sistem. Yaitu, sejumlah besar upaya tidak berhasil yang gagal untuk memasuki sistem menarik perhatian Anda dibandingkan dengan yang sukses. Setelah menganalisis proyek, ternyata alasan untuk ini adalah kesalahan di frontend, karena bagian antarmuka proyek terus-menerus mengirimkan permintaan yang sesuai ke server API untuk memasuki sistem.

▍21. Ukur cakupan kode logis dengan tes menggunakan pengujian mutasi

Rekomendasi

Metrik tolok ukur tradisional mungkin tidak dapat diandalkan. Jadi, dalam laporan itu bisa ada angka 100%, tetapi pada saat yang sama, benar-benar semua fungsi proyek akan mengembalikan nilai yang salah. Bagaimana menjelaskannya? Faktanya adalah bahwa indikator cakupan kode dengan tes hanya menunjukkan baris kode mana yang dieksekusi di bawah kendali sistem pengujian, tetapi tidak tergantung pada apakah sesuatu telah benar-benar diverifikasi, yaitu, pada apakah ada pernyataan pengujian ditujukan untuk memeriksa kebenaran hasil kode. Ini menyerupai seseorang yang, kembali dari perjalanan bisnis ke luar negeri, menunjukkan perangko di paspornya. Perangko membuktikan bahwa dia pergi ke suatu tempat, tetapi mereka tidak mengatakan apa-apa tentang apakah dia melakukan apa yang dia lakukan dalam perjalanan bisnis.

Di sini, tes mutasi dapat membantu kami, yang memungkinkan kami untuk mengetahui berapa banyak kode yang benar-benar diuji, dan tidak hanya dikunjungi oleh sistem pengujian. Untuk pengujian mutasi, Anda dapat menggunakan perpustakaan Stryker JS. Berikut adalah prinsip-prinsip yang digunakannya:

1. Dia sengaja mengubah kode, membuat kesalahan di dalamnya. Misalnya, kode newOrder.price===0 berubah menjadi newOrder.price!=0 . "Kesalahan" ini disebut mutasi.
2. Dia menjalankan tes. Jika mereka ternyata lulus, maka kita memiliki masalah, karena tes tidak memenuhi tugas mereka mendeteksi kesalahan, dan "mutan", seperti yang mereka katakan, "bertahan". Jika tes menunjukkan kesalahan dalam kode, maka semuanya dalam urutan - "mutan" "mati".

Jika ternyata semua "mutan" "terbunuh" (atau, paling tidak, sebagian besar dari mereka tidak bertahan hidup), ini memberikan tingkat kepercayaan yang lebih tinggi pada kualitas tinggi kode dan tes yang mengujinya daripada metrik tradisional untuk menutup kode dengan tes. Pada saat yang sama, waktu yang diperlukan untuk mengonfigurasi dan melakukan pengujian mutasi sebanding dengan yang diperlukan saat menggunakan tes konvensional.

Konsekuensi Penyimpangan dari Rekomendasi

Jika indikator tradisional cakupan kode oleh tes menunjukkan bahwa 85% dari kode dicakup oleh tes, ini tidak berarti bahwa tes dapat mendeteksi kesalahan dalam kode ini.

Pendekatan yang salah

Berikut adalah contoh cakupan 100% dari kode dengan tes, di mana kode sama sekali tidak diuji.

 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%, ,   ,     

Pendekatan yang benar

Berikut ini adalah laporan uji mutasi yang dihasilkan oleh perpustakaan Stryker. Ini memungkinkan Anda untuk mengetahui berapa banyak kode yang tidak diuji (ini ditunjukkan oleh jumlah "yang bertahan" "mutan").


Laporan Stryker

Hasil laporan ini memungkinkan dengan keyakinan lebih dari indikator cakupan kode biasa dengan tes untuk mengatakan bahwa tes bekerja seperti yang diharapkan.

• Mutasi adalah kode yang sengaja dimodifikasi oleh perpustakaan Stryker untuk menguji efektivitas tes.
• Jumlah "terbunuh" "mutan" (terbunuh) menunjukkan jumlah cacat kode yang sengaja dibuat ("mutan") yang diidentifikasi selama pengujian.
• Jumlah "selamat" "mutan" (selamat) memungkinkan Anda untuk mengetahui berapa banyak tes cacat kode belum ditemukan.

Bagian 4. Integrasi Berkelanjutan, Indikator Kualitas Kode Lainnya

▍ 22. Manfaatkan kemampuan linter dan sela proses pembangunan proyek ketika mendeteksi masalah yang mereka laporkan

Rekomendasi

Saat ini, linter adalah alat yang ampuh yang dapat mengidentifikasi masalah kode serius. Disarankan, selain beberapa aturan dasar linting (seperti yang diterapkan oleh eslint-plugin-standard dan eslint-config-airbnb plugins ), gunakan aturan khusus. Sebagai contoh, ini adalah aturan yang diterapkan oleh plugin eslint-plugin-chai-expect untuk memverifikasi kebenaran kode tes, ini adalah aturan dari plugin eslint-plugin-janji yang mengontrol pekerjaan dengan janji, ini adalah aturan dari eslint-plugin-keamanan yang memeriksa kode untuk kehadiran itu berisi ekspresi reguler yang berbahaya. Di sini Anda juga dapat menyebutkan plugin eslint-plugin-you-dont-need-lodash-garis bawah , yang memungkinkan Anda untuk menemukan dalam kode penggunaan metode dari perpustakaan eksternal yang memiliki analog dalam JavaScript murni.

Konsekuensi Penyimpangan dari Rekomendasi

Suatu hari hujan telah tiba, proyek memberikan kegagalan terus menerus dalam produksi, dan tidak ada informasi tentang tumpukan kesalahan dalam log. Apa yang terjadi Ternyata, apa yang dilemparkan kode sebagai pengecualian bukanlah objek kesalahan. Akibatnya, informasi tentang tumpukan tidak masuk ke log. Sebagai soal fakta, dalam situasi seperti itu, programmer dapat membunuh dinding atau, lebih baik, menghabiskan 5 menit menyiapkan linter, yang akan dengan mudah mendeteksi masalah dan memastikan proyek dari masalah serupa yang mungkin timbul di masa depan.

Pendekatan yang salah

Berikut adalah kode yang, secara tidak sengaja, melempar objek biasa sebagai pengecualian, sementara di sini Anda memerlukan objek tipe Error . Jika tidak, data tentang tumpukan tidak akan masuk ke log. ESLint menemukan apa yang dapat menyebabkan masalah produksi, membantu menghindari masalah ini.


ESLint membantu Anda menemukan bug dalam kode Anda

▍23. Umpan Balik Lebih Cepat dengan Pengembang Menggunakan Integrasi Berkelanjutan Lokal

Rekomendasi

Menggunakan sistem integrasi terpusat yang terpusat, yang membantu mengontrol kualitas kode, mengujinya, menggunakan linter, memeriksa kerentanannya? Jika demikian, pastikan pengembang dapat menjalankan sistem ini secara lokal. Ini akan memungkinkan mereka untuk langsung memeriksa kode mereka, yang mempercepat umpan balik dan mengurangi waktu pengembangan proyek. Kenapa begitu? Proses pengembangan dan pengujian yang efektif melibatkan banyak operasi berulang yang berulang. Kode diuji, kemudian pengembang menerima laporan, lalu, jika perlu, kode tersebut direaktor, setelah itu semuanya diulang. Semakin cepat loop umpan balik bekerja, semakin cepat pengembang menerima laporan tentang pengujian kode, semakin banyak iterasi peningkatan kode ini yang dapat mereka lakukan. Jika membutuhkan banyak waktu untuk mendapatkan laporan pengujian, ini dapat menyebabkan kualitas kode yang buruk. Katakanlah seseorang sedang mengerjakan beberapa modul, kemudian mulai mengerjakan sesuatu yang lain, kemudian menerima laporan tentang modul, yang menunjukkan bahwa modul perlu ditingkatkan. Namun, sudah sibuk dengan hal-hal yang sama sekali berbeda, pengembang tidak akan cukup memperhatikan modul masalah.

Beberapa penyedia solusi CI (katakanlah ini berlaku untuk CircleCI ) memungkinkan Anda menjalankan pipa CI secara lokal. Beberapa alat berbayar, seperti Wallaby.js (penulis mencatat bahwa ia tidak terhubung dengan proyek ini), dapat dengan cepat mendapatkan informasi berharga tentang kualitas kode. Selain itu, pengembang hanya dapat menambahkan skrip npm yang sesuai ke package.json , yang melakukan pemeriksaan kualitas kode (tes, analisis dengan linter, mencari kerentanan), dan bahkan menggunakan paket bersamaan untuk mempercepat pemeriksaan. Sekarang, untuk memeriksa kode secara komprehensif, itu akan cukup untuk menjalankan satu perintah, seperti npm run quality , dan segera mendapatkan laporan. Selain itu, jika tes kode menunjukkan bahwa ia memiliki masalah, Anda dapat membatalkan komit menggunakan kait git (perpustakaan husky dapat berguna untuk menyelesaikan masalah ini).

Konsekuensi Penyimpangan dari Rekomendasi

Jika pengembang menerima laporan tentang kualitas kode sehari setelah menulis kode ini, laporan seperti itu kemungkinan akan berubah menjadi seperti dokumen formal, dan tes kode akan dipisahkan dari pekerjaan, tidak menjadi bagian alami.

Pendekatan yang benar

Berikut ini adalah skrip npm yang memeriksa kualitas kode. Melakukan pemeriksaan diparalelkan. Script dieksekusi ketika mencoba mengirim kode baru ke repositori. Selain itu, pengembang dapat meluncurkannya atas inisiatifnya sendiri.

 "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. Lakukan pengujian ujung ke ujung pada cermin lingkungan produksi yang realistis

Rekomendasi

Dalam ekosistem Kubernetes yang luas, masih ada konsensus untuk menggunakan alat yang cocok untuk menyebarkan lingkungan lokal, meskipun alat tersebut cukup sering muncul. Salah satu pendekatan yang mungkin di sini adalah menjalankan Kubernet yang “diperkecil” menggunakan alat-alat seperti Minikube atau MicroK8s , yang memungkinkan Anda untuk menciptakan lingkungan yang ringan yang menyerupai yang asli. Pendekatan lain adalah menguji proyek di lingkungan Kubernetes "nyata" yang terpencil. Beberapa penyedia CI (seperti Codefresh ) memungkinkan untuk berinteraksi dengan lingkungan bawaan Kubernetes, yang menyederhanakan pekerjaan pipa CI saat menguji proyek dunia nyata. Yang lain memungkinkan Anda untuk bekerja dengan lingkungan Kubernetes yang jauh.

Konsekuensi Penyimpangan dari Rekomendasi

Penggunaan berbagai teknologi dalam produksi dan pengujian membutuhkan dukungan dari dua model pengembangan dan mengarah pada pemisahan tim pemrogram dan spesialis DevOps.

Pendekatan yang benar

Berikut ini adalah contoh dari rantai CI, yang, seperti yang mereka katakan, dengan cepat menciptakan cluster Kubernetes (ini diambil dari sini ).

 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. Berusaha untuk memparalelkan pelaksanaan pengujian

Rekomendasi

Jika sistem pengujian terorganisir dengan baik, itu akan menjadi teman setia Anda, 24 jam sehari siap melaporkan masalah dengan kode. Untuk melakukan ini, tes harus dilakukan dengan sangat cepat. Dalam praktiknya, ternyata menjalankan dalam mode single-threaded 500 unit tes yang menggunakan prosesor secara intensif membutuhkan terlalu banyak waktu. Dan tes semacam itu perlu dilakukan cukup sering. Untungnya, alat modern untuk menjalankan tes ( Jest , AVA , ekstensi untuk Mocha ) dan platform CI dapat menjalankan tes secara paralel menggunakan beberapa proses, yang secara signifikan dapat meningkatkan kecepatan menerima laporan pengujian. Beberapa platform CI bahkan tahu bagaimana memparalelkan pengujian antar wadah, yang selanjutnya meningkatkan loop umpan balik. Agar berhasil melakukan paralelisasi terhadap pengujian, lokal atau jarak jauh, pengujian tidak boleh saling bergantung. Tes mandiri dapat dijalankan dalam proses yang berbeda tanpa masalah.

Konsekuensi Penyimpangan dari Rekomendasi

Mendapatkan hasil pengujian satu jam setelah mengirim kode ke repositori saat mengerjakan fitur proyek baru adalah cara yang bagus untuk mengurangi kegunaan hasil pengujian.

Pendekatan yang benar

Berkat pelaksanaan tes paralel, perpustakaan mocha-parallel-test dan kerangka Jest mudah memotong Mocha ( ini adalah sumber informasi ini).


Uji alat pengujian kinerja

▍26. Lindungi diri Anda dari masalah hukum dengan menggunakan verifikasi lisensi dan verifikasi kode plagiarisme

Rekomendasi

Mungkin sekarang Anda tidak terlalu khawatir tentang masalah dengan hukum dan plagiarisme. Namun, mengapa tidak memeriksa proyek Anda untuk masalah yang sama? Ada banyak alat yang tersedia untuk mengatur inspeksi semacam itu. Sebagai contoh, ini adalah pemeriksa lisensi dan pemeriksa plagiarisme (ini adalah paket komersial, tetapi ada kemungkinan penggunaannya gratis). Mudah untuk mengintegrasikan pemeriksaan semacam itu ke dalam pipa CI dan memeriksa proyek, misalnya, untuk keberadaan dependensi dengan lisensi terbatas, atau untuk keberadaan kode yang disalin dari StackOverflow dan mungkin melanggar hak cipta orang lain.

Konsekuensi Penyimpangan dari Rekomendasi

Pengembang, secara tidak sengaja, dapat menggunakan paket dengan lisensi yang tidak cocok untuk proyeknya, atau menyalin kode komersial, yang dapat menyebabkan masalah hukum.

Pendekatan yang benar

Instal paket pemeriksa lisensi secara lokal atau dalam lingkungan CI:

 npm install -g license-checker 

Kami akan memeriksa lisensinya, dan jika dia menemukan sesuatu yang tidak sesuai dengan kami, kami akan menganggap cek itu tidak berhasil. Sistem CI, setelah mendeteksi bahwa ada masalah ketika memeriksa lisensi, akan menghentikan perakitan proyek.

 license-checker --summary --failOn BSD 

Pemeriksaan Lisensi

▍27. Terus memeriksa proyek untuk dependensi rentan

Rekomendasi

Bahkan paket yang sangat dihormati dan andal, seperti Express, memiliki kerentanan. Untuk mengidentifikasi kerentanan semacam itu, Anda dapat menggunakan alat khusus - seperti alat standar untuk mengaudit paket npm atau proyek snyk komersial, yang memiliki versi gratis. Pemeriksaan ini, bersama dengan yang lain, dapat menjadi bagian dari pipa CI.

Konsekuensi Penyimpangan dari Rekomendasi

Untuk melindungi proyek Anda dari kerentanan ketergantungannya tanpa menggunakan alat khusus, Anda harus terus memantau publikasi tentang kerentanan tersebut. Ini adalah tugas yang sangat memakan waktu.

Pendekatan yang benar

Berikut adalah hasil verifikasi proyek menggunakan NPM Audit.


Laporan Paket Periksa Kerentanan

▍28. Otomatis pembaruan ketergantungan

Rekomendasi

Jalan menuju neraka ditaburi dengan niat baik. Ide ini sepenuhnya berlaku untuk file package-lock.json , yang penggunaannya, secara default, memblokir pembaruan paket. Ini terjadi bahkan dalam kasus ketika proyek dibawa ke keadaan sehat oleh perintah npm install dan npm update . Hal ini mengarah, paling baik, ke penggunaan paket yang sudah ketinggalan zaman, atau, paling buruk, ke tampilan kode rentan dalam proyek. Tim pengembangan, sebagai akibatnya, bergantung pada pembaruan manual informasi tentang versi paket yang sesuai, atau pada utilitas seperti ncu , yang, sekali lagi, diluncurkan secara manual. Proses memperbarui dependensi adalah yang terbaik secara otomatis, dengan fokus pada penggunaan versi yang paling dapat diandalkan dari paket yang digunakan dalam proyek. Ini bukan satu-satunya solusi yang tepat, namun, dalam mengotomatisasi pembaruan paket, ada beberapa pendekatan yang patut diperhatikan. Yang pertama adalah menyuntikkan sesuatu seperti memeriksa paket menggunakan npm-outdated atau npm-check-updates (ncu) ke dalam pipa CI. Ini akan membantu mengidentifikasi paket-paket usang dan mendorong pengembang untuk memutakhirkannya. Pendekatan kedua adalah menggunakan alat komersial yang memeriksa kode dan secara otomatis membuat permintaan tarik yang bertujuan memperbarui dependensi. Di bidang pembaruan ketergantungan otomatis, kami dihadapkan dengan pertanyaan menarik lainnya mengenai kebijakan pembaruan. Jika diperbarui dengan masing-masing tambalan baru, pembaruan tersebut dapat memberi terlalu banyak tekanan pada sistem. Jika Anda memperbarui segera setelah rilis versi utama berikutnya dari paket, ini dapat menyebabkan penggunaan solusi yang tidak stabil dalam proyek (kerentanan dalam banyak paket ditemukan pada hari-hari pertama setelah rilis, baca tentang insiden dengan 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 

Ringkasan

, , . , , .

Pembaca yang budiman! ?