Bagaimana CI dapat digunakan untuk bahasa yang ditafsirkan?

23

Saya belum pernah menggunakan Continuous Integration system (CI) sebelumnya. Saya terutama kode dalam MATLAB, Python atau PHP. Tidak satu pun dari ini memiliki langkah membangun dan saya tidak melihat bagaimana CI dapat digunakan untuk pekerjaan saya. Seorang teman di sebuah proyek besar di sebuah perusahaan besar memberi tahu saya bahwa bahasa tidak masalah.

Saya tidak melihat bagaimana CI akan berguna bagi saya jika saya tidak memiliki langkah pembangunan. Saya dapat menganggap CI sebagai lingkungan pengujian yang akan menjalankan unit test. Apakah saya melewatkan sesuatu?

— Tuan Loh.
sumber

8

"Benda-benda ini ortogonal ..."

— nyamuk

14

Apakah ini benar tergantung pada apa yang Anda anggap sebagai "langkah membangun". Anda tampaknya menganggapnya sebagai kompilasi minimum, untuk memberikan Anda sesuatu yang bisa dijalankan. Di tim saya, kami menganggap build adalah kompilasi, analisis statis, dan tes unit (dengan ruang untuk lebih banyak tugas). Definisi ini memiliki keuntungan bahwa komit yang gagal dalam pengujian unit tidak "membangun" dan tidak diizinkan masuk ke dalam repo untuk memulai.

— Chris Hayes

Memperluas pada poin Chris, sistem CI dapat dan harus menguji setiap dan semua tes otomatis - kompilasi dan penautan dapat dilihat sebagai salah satu bentuk tes otomatis. Jika Anda memiliki keterbatasan sumber daya, beberapa pengujian yang lebih lambat mungkin hanya berjalan pada build malam hari, atau bahkan build akhir pekan, tetapi CI akan menjalankannya. Tanyakan pada diri Anda sendiri: Mengapa Anda ingin mengotomatiskan tes tetapi masih menjalankan tes otomatis secara manual?

— Peter - Unban Robert Harvey

32

Integrasi berkelanjutan sebagai istilah mengacu pada dua gagasan berbeda.

Yang pertama adalah alur kerja: alih-alih semua orang dalam tim bekerja di cabang mereka sendiri dan kemudian setelah beberapa minggu pemrograman mencoba untuk menggabungkan perubahan mereka ke dalam arus utama, perubahan itu terintegrasi (hampir) terus menerus. Ini memungkinkan masalah muncul lebih awal, dan menghindari perubahan yang tidak kompatibel. Namun, itu mensyaratkan bahwa kita dapat dengan mudah memeriksa apakah suatu perubahan “berfungsi”.

Di sinilah ide kedua masuk, yang ternyata jauh lebih populer. Server CI adalah lingkungan yang bersih tempat perubahan diuji secepat mungkin. Lingkungan bersih diperlukan agar bangunan dapat direproduksi. Jika berhasil sekali, itu harus selalu berhasil. Ini menghindari masalah "tetapi berhasil pada mesin saya". Secara khusus, server CI berharga ketika perangkat lunak Anda berjalan pada sistem yang berbeda atau dalam konfigurasi yang berbeda dan Anda perlu memastikan semuanya berfungsi.

Kurangnya langkah pembangunan tidak relevan. Namun, CI hanya masuk akal jika Anda memiliki test suite. Paket tes ini harus otomatis, dan tidak boleh gagal. Jika pengujian gagal, pengembang yang sesuai harus mendapatkan notifikasi sehingga mereka dapat memperbaiki masalah yang mereka perkenalkan (“melanggar build”, bahkan ketika tidak ada build sebagai kompilasi).

Ternyata server semacam itu berharga untuk lebih dari sekadar pengujian. Bahkan, sebagian besar perangkat lunak CI benar-benar jelek dalam menjalankan tes dalam berbagai konfigurasi, tetapi pandai mengelola semua jenis pekerjaan. Misalnya selain tes unit "terus menerus", mungkin ada tes penuh sebagai bangunan malam. Perangkat lunak ini dapat diuji dengan beberapa versi Python, versi pustaka yang berbeda. Situs web dapat diuji untuk tautan mati. Kita dapat menjalankan analisis statis, pemeriksa gaya, alat cakupan uji, dll. Di atas kode. Dokumentasi dapat dihasilkan. Ketika semua suite tes lulus, proses pengemasan dapat dimulai sehingga Anda siap untuk merilis perangkat lunak Anda. Ini berguna dalam pengaturan yang gesit di mana Anda menginginkan produk yang dapat digunakan (dan dapat didemonstrasikan) setiap saat. Dengan maraknya aplikasi web, ada juga gagasan penyebaran berkelanjutan: Jika semua tes lulus, kami dapat secara otomatis mendorong perubahan ke produksi. Tentu saja, ini mengharuskan Anda benar-benar percaya diri dalam test suite Anda (jika tidak, Anda memiliki masalah yang lebih besar).

— amon
sumber

3

"CI hanya masuk akal jika Anda memiliki rangkaian uji" - perhatikan bahwa untuk bahasa yang dikompilasi, kompiler itu sendiri adalah rangkaian uji dasar yang menangkap banyak kesalahan umum.

— user253751

@ imibis Saya pikir itu bukan tentang dikompilasi vs ditafsirkan, tetapi tentang pengetikan statis. Bahasa dengan sistem tipe statis dapat secara otomatis membuktikan sifat kebenaran tertentu. Ini bahkan lebih baik daripada tes yang hanya bekerja dengan contoh. Satu-satunya masalah umum yang ditemukan oleh server CI ketika melakukan kompilasi adalah bahwa seorang dev lupa untuk melakukan file baru; dalam semua kasus lain kita tidak benar-benar membutuhkan server CI dan bisa mengkompilasi secara lokal untuk memeriksa kesalahan.

— amon

1

@amon Tidak Benar. Tidak jarang membuat perubahan menit terakhir dan kemudian lupa untuk menguji kompilasi sebelum melakukan. Itu juga menangkap masalah ketika Anda menambahkan dependensi pada sesuatu yang Anda instal secara global tetapi tidak diinstal di tempat lain.

— jpmc26

24

Benar, Anda tidak memiliki kebutuhan khusus sistem CI untuk melakukan build dan mengecek apakah build tersebut benar, tetapi itu hanya bagian dari apa yang dimaksud dengan CI.

Tujuan CI adalah untuk mendeteksi kesalahan sesegera mungkin, karena secara umum, semakin cepat kesalahan diketahui, semakin murah untuk memperbaikinya. Untuk itu, dalam kasus di mana langkah pembuatan tidak diperlukan, sistem CI masih dapat mengotomatiskan penggunaan alat analisis kode, penyebaran ke lingkungan pengujian, unit / integrasi / regresi / pengujian lain yang Anda bisa mengotomatisasi, dan langkah-langkah lainnya Anda dapat melakukan secara otomatis untuk memeriksa kesalahan.

— Iker
sumber

8

Saya akan menambahkan: cara yang paling jelas untuk menguji sistem secara otomatis adalah dengan menjalankannya secara otomatis . Misalnya Anda dapat menguji situs web menggunakan alat seperti JMeter atau Selenium.

— reinierpost

7

Integrasi berkelanjutan berfungsi lebih dari sekadar kompilasi kode. Jika hanya itu yang dilakukannya, maka kita tidak akan membutuhkan hampir banyak alat untuk itu!

Beberapa tugas lain yang dapat saya pikirkan begitu saja yang sering dilakukan oleh pipeline integrasi berkelanjutan:

Menjalankan tes otomatis. (Python memiliki banyak perpustakaan pengujian otomatis, dan PHP memiliki setidaknya beberapa. Saya tidak dapat berbicara dengan MATLAB.)
Bundling perangkat lunak untuk distribusi. Dengan mengotomatiskan proses ini, Anda memastikan bahwa itu dilakukan dengan cara yang tepat, konsisten, dan berulang setiap saat. Tidak ada langkah yang akan dilupakan; menghasilkan paket distribusi seperti itu membutuhkan paling banyak satu klik. (Menggabungkan aplikasi Python Anda sebagai roda adalah ide yang bagus!)
Menandai tonggak komitmen. Setiap kali Anda membuat paket untuk produksi, Anda mungkin ingin menandainya.
Menambah nomor versi secara otomatis. Biasanya ini hanya akan menjadi nomor "build" dan bukan bagian yang lebih bermakna, tetapi bisa menyenangkan untuk secara unik mengidentifikasi bangunan tertentu, sehingga Anda tahu apa yang digunakan di mana.

Melangkah lebih jauh ke garis perbatasan "integrasi berkelanjutan" dalam arti yang ketat, Anda juga bisa melakukan ini:

Memiliki proses otomatis untuk mengatur sistem operasi dan menginstal dependensi Anda.
Menyebarkan salinan perangkat lunak secara otomatis (terutama berguna untuk aplikasi web atau perangkat lunak yang didistribusikan oleh manajer paket). Beberapa tim benar-benar menggunakan ini untuk menyebarkan ke produksi (pengiriman berkelanjutan), tetapi bahkan jika Anda tidak, Anda masih dapat memanfaatkan ini untuk menyebarkan salinan kode non-produksi tambahan. Untuk beberapa proyek tempat saya bekerja, kami memiliki salinan untuk pengembang untuk menguji kode mereka sebelum membuatnya tersedia untuk QA, salinan untuk QA untuk diuji, dan salinan yang lebih "stabil" untuk tujuan demoing.

Intinya sederhana ini: ada tugas yang harus Anda lakukan secara berkala dalam proses pengembangan perangkat lunak selain hanya menulis kode. Dengan mengotomatisasi tugas-tugas ini dan menjalankannya di server, Anda dapat

Proses yang konsisten (Anda tidak akan membuat Stan dan Sally melakukan hal-hal dengan cara yang berbeda.)
Pengetahuan tentang proses yang direkam dalam kode (Siapa pun yang dapat membaca skrip dapat mempelajari langkah-langkah yang terlibat dalam penerapan, alih-alih Sally menjadi satu-satunya yang melakukannya atau tahu caranya.)
Duplikasi proses yang lebih sederhana (Sederhana untuk menyebarkan banyak salinan situs web: Anda baru saja memberikan konfigurasi baru!)
Pengujian yang lebih menyeluruh (Bob hanya menguji halamannya, tetapi perubahannya merusak halaman Sally. Sally lupa untuk melakukan file. Stan menambahkan ketergantungan baru yang harus diinstal bersama aplikasi tetapi tidak menyadarinya karena diinstal secara otomatis oleh IDE Saya telah melihat semua ini dalam beberapa bentuk.)

Dan mungkin beberapa manfaat lain yang bahkan tidak terpikirkan.

— jpmc26
sumber

Terima kasih atas jawabannya. Contohnya bagus. Saya berharap saya dapat memilih lebih dari satu jawaban yang diterima: - /

— Lord Loh.

@ LordLoh. Jangan khawatir. Aku senang bisa membantu. =) Terima kasih telah memberi tahu saya.

— jpmc26

1

Terpilih, jawaban yang bagus. Seperti apa pun, jika dilakukan dengan buruk, Anda mungkin tidak mendapatkan manfaat yang diiklankan. Konsistensi EG, pengetahuan proses, kesederhanaan semua mungkin menderita jika Anda membangun kembali. Jadi ... evaluasi kebutuhan Anda secara realistis dan kecepatan Tuhan!

— brian_o

1

Anda mungkin tidak perlu mengkompilasi solusi, tetapi CI masih dapat membantu Anda dengan mengubah file konfigurasi / jalur folder dll. Dan jika Anda berada dalam tim - mempromosikan perubahan ke status prod dan menyebarkannya

Katakanlah Anda menyebarkan kode Python ke 5 server QA yang berbeda dan memerlukannya menunjuk ke database QA yang berbeda, dan kemudian setelah pengujian otomatis dijalankan (dipicu oleh CI), mempromosikan build ke produksi dan menyebarkannya di sana dengan perubahan konfigurasi yang sesuai untuk setiap server produksi .

— Mike
sumber