Saya ingin segera memesan: artikel ini tidak memberikan resep yang siap digunakan. Ini lebih merupakan kisah perjalanan saya ke dunia Scriptres dan NodeJS, serta hasil percobaan saya. Namun demikian, di akhir artikel akan ada tautan ke repositori GitLab, yang dapat Anda lihat, dan mungkin mengambil sesuatu yang Anda sukai untuk diri sendiri. Mungkin bahkan dalam pengalaman saya, buat solusi otomatis Anda sendiri.

Mengapa itu perlu?

Jadi, mengapa Anda perlu membuat perpustakaan sama sekali, atau dalam kasus paket NPM tertentu?

1. Menggunakan kembali kode antar proyek.
   
   Semuanya dimulai dengan fakta bahwa saya memperhatikan kebiasaan membuat folder / alat dalam proyek. Selain itu, saya juga membawa sebagian besar folder ini ketika saya beralih ke proyek baru. Dan kemudian saya bertanya pada diri sendiri, mengapa tidak membuat paket NPM alih-alih menyalin dan kemudian menghubungkannya ke proyek apa pun?
2. Siklus hidup yang berbeda. Dalam salah satu aplikasi, ada banyak komponen perusahaan sebagai ketergantungan. Itu mungkin untuk memperbaruinya hanya secara keseluruhan, bahkan jika hanya satu komponen yang diperbarui. Perubahan pada komponen lain dapat merusak sesuatu dan tidak selalu kami memiliki perkiraan waktu yang cukup untuk pengujian ulang. Model ini sangat merepotkan. Ketika setiap paket melayani tujuannya atau serangkaian kecil tujuan terkait, mereka sudah dapat diperbarui ketika benar-benar dibutuhkan. Juga, versi berikut dari paket ini dirilis hanya ketika mereka memiliki beberapa perubahan, dan bukan "untuk perusahaan."
3. Pisahkan kode minor dari logika bisnis inti. DDD memiliki prinsip distilasi domain, yang melibatkan mengidentifikasi potongan-potongan kode yang bukan milik domain utama dan mengisolasi diri dari mereka. Dan bagaimana cara lebih baik untuk mengisolasi daripada mengambil kode ini ke proyek yang terpisah.
   Omong-omong, distilasi domain sangat mirip dengan prinsip SRP hanya pada tingkat yang berbeda.
4. Cakupan kode sendiri. Di salah satu proyek tempat saya berpartisipasi, cakupan kode sekitar 30%. Dan perpustakaan yang saya ambil memiliki cakupan sekitar 100%. Proyek, meskipun kehilangan persentase cakupan, karena berada di zona merah sebelum pemindahan, tetap ada. Dan perpustakaan memiliki indikator yang patut ditiru hingga hari ini, setelah hampir satu tahun dan 4 versi utama.
5. Sumber terbuka Kode yang tidak mengandung logika bisnis adalah kandidat pertama untuk pemisahan dari proyek, sehingga dapat dibuat terbuka.

Luncurkan perpustakaan baru "mahal"

Ada masalah seperti itu: untuk membuat perpustakaan tidak cukup untuk mendapatkan repositori git di bawahnya. Anda juga perlu mengonfigurasi tugas agar proyek dapat dirakit, melakukan verifikasi statis (serat) dan pengujian. Selain itu, selain pengujian, disarankan untuk mengumpulkan cakupan kode. Selain itu, Anda harus mempublikasikan paket secara manual setiap kali. Dan masih perlu menulis readme. Itu hanya dengan readme saya tidak bisa membantu.

Jadi, apa yang bisa dilakukan dengan semua tugas yang membosankan dan tidak menarik ini?

Langkah pertama: Benih

Saya mulai dengan membuat proyek benih. Ini semacam starter kit, ia memiliki struktur yang sama dengan proyek pertama saya untuk mengambil kode ke dalam paket terpisah. Saya menciptakan tugas-tugas dan skrip-skrip yang akan membangun, menguji, dan mengumpulkan cakupan paket dalam satu tindakan. Sekarang, untuk membuat proyek lain, saya perlu mengkloning seed ke folder baru dan mengubah asal sehingga akan menunjuk ke repositori yang baru dibuat di GitHub (maka saya masih menggunakan GitHub).

Cara membuat proyek ini memberikan keuntungan lain. Sekarang, perubahan yang berkaitan dengan konstruksi atau pengujian proyek dilakukan satu kali, dalam proyek benih. Dan salin-tempel perubahan ini tidak lagi diperlukan. Alih-alih, dalam tugas akhir, di lain waktu saya harus bekerja dengannya, saya membuat seed kedua yang disebut remote dan mengambil perubahan ini dari sana.

Dan itu bekerja untuk saya untuk sementara waktu. Sampai saya menggunakan seed dalam proyek di mana beberapa pengembang berpartisipasi. Saya menulis instruksi dalam tiga langkah: ambil master terakhir, buat dan publikasikan. Dan pada titik tertentu, salah satu pengembang, karena alasan tertentu, menyelesaikan langkah pertama dan ketiga. Bagaimana ini mungkin?

Langkah Kedua: Publikasikan Otomatis

Terlepas dari kenyataan bahwa itu adalah kesalahan tunggal, tindakan manual seperti penerbitan itu membosankan. Karena itu, saya pikir perlu untuk mengotomatiskannya. Selain itu, CI diperlukan untuk mencegah komit merah masuk ke master. Awalnya saya mencoba menggunakan Travis CI, tetapi berlari ke batasan berikut. Dia menganggap tarik-permintaan di master setara dengan komit di master. Dan saya harus melakukan hal yang berbeda.

Salah satu kolega saya menyarankan saya untuk memperhatikan GitLab dan CI-nya, dan semua yang saya inginkan bekerja di sana.

Saya membuat proses bekerja dengan proyek berikut, yang digunakan ketika Anda harus memperbaiki bug, menambahkan fungsionalitas baru atau membuat versi baru:

1. Saya membuat cabang dari master. Saya menulis kode dan tes di dalamnya.
2. Saya membuat permintaan penggabungan.
3. GitLab CI secara otomatis menjalankan tes dalam node: wadah terbaru
4. Permintaan melewati Peninjauan Kode.
5. Setelah permintaan dibekukan, GitLab menjalankan set script kedua. Set ini membuat tag pada komit dengan nomor versi. Nomor versi diambil dari package.json, jika ada peningkatan secara manual di sana, jika tidak, maka versi yang diterbitkan terakhir diambil dan ditambahkan secara otomatis.
6. Script membangun proyek dan menjalankan tes lagi.
7. Pada langkah-langkah terakhir, tag versi dikirim ke repositori dan paket diterbitkan ke NPM.

Dengan demikian, versi yang ditunjukkan dalam tag selalu cocok dengan versi paket yang diterbitkan dari komit ini. Agar operasi ini dapat berfungsi, Anda perlu menentukan variabel lingkungan dengan kunci akses ke repositori dan NPM dalam proyek GitLab.

Langkah Terakhir: Otomatiskan Semuanya

Pada titik ini, saya sudah otomatis banyak, tetapi masih ada banyak tindakan manual untuk membuat proyek. Ini, tentu saja, sudah mengalami kemajuan, karena tindakan dilakukan sekali per proyek, dan bukan pada setiap versi. Tapi tetap saja, instruksinya terdiri dari 11 langkah. Dan saya sendiri keliru beberapa kali dengan mengambil langkah-langkah ini. Lalu saya memutuskan bahwa sejak saya mulai mengotomatisasi, saya harus membawa ini sampai akhir.

Agar otomasi lengkap ini berfungsi, tetapi komputer saya harus memiliki 3 file di folder .ssh. Saya pikir folder ini cukup terlindungi, karena kunci pribadi id_rsa sudah tersimpan di sana. File ini juga akan digunakan untuk mengaktifkan GitLab CI untuk mengirimkan tag ke repositori.

File kedua yang saya taruh di sana adalah "gitlab", berisi kunci akses ke API GitLab. Dan file ketiga adalah "npm", kunci akses untuk menerbitkan paket.

Dan kemudian keajaiban dimulai. Yang Anda butuhkan untuk membuat paket baru adalah menjalankan satu perintah di folder seed: "gulp startNewLib -n [npmName] / [libName]". Selesai, paket dibuat, siap untuk pengembangan dan publikasi otomatis.

Sebagai contoh, paket "vlr / validity" dibuat dengan cara ini.

Perintah ini melakukan hal berikut:

1. Membuat proyek di GitLab
2. Klon mengunggah ke folder lokal di sebelah folder tempat perintah dijalankan.
3. Perubahan asal ke proyek yang dibuat pada langkah 1
4. Dorong cabang master
5. Membuat variabel lingkungan dalam proyek dari file dalam folder .ssh
6. Membuat cabang Implementasi pertama
7. Mengubah nama perpustakaan di package.json, melakukan dan mendorong cabang

Yang Anda butuhkan setelah ini adalah meletakkan kode di sana dan membuat permintaan penggabungan.

Sebagai hasilnya, yang dapat dibanggakan, dari saat ketika diputuskan untuk menempatkan semacam kode ke proyek terpisah hingga versi pertama diterbitkan, dibutuhkan sekitar lima menit. Empat dari mereka menempati dua jalur pipa GitLabCI, dan satu menit untuk meluncurkan perintah di atas, seret dan letakkan kode, dan klik tombol di antarmuka GitLab untuk membuat dan kemudian menahan permintaan.

Ada beberapa batasan: Nama GitLab harus cocok dengan nama di npm. Namun, perintah ini, tidak seperti fungsi lainnya dalam proyek seed, hanya berfungsi pada Windows.

Jika Anda tertarik dengan proyek seed ini, Anda dapat mempelajarinya di tautan berikut .