Apa tujuan dari mesin build khusus?

Karena beberapa keadaan yang menyebabkan siklus pembangunan terakhir pemasangan yang buruk, saya berkampanye di kantor kami untuk melakukan semua penyebaran di masa mendatang dengan mesin pembuat khusus, dan bos saya menerima proposal ini.

Namun, alih-alih mendapatkan mesin yang sebenarnya di kantor kami untuk digunakan, kami harus berbagi satu mesin dengan beberapa kelompok lain - dan kerumitan harus meninggalkan kantor saya dengan semua informasi yang diperlukan dan kemudian berjalan menuruni tangga ke kantor lain hanya untuk melakukan pembangunan sederhana membuat saya bertanya-tanya mengapa saya pernah mengusulkan ini di tempat pertama.

Gagasan untuk memiliki mesin build yang terpisah, pada awalnya, adalah untuk memisahkan kode saya yang ditulis secara lokal dari kode beberapa pengembang lain, dan untuk memisahkan file yang dibajak di komputer saya dari penyebaran. Itu juga untuk menyelesaikan masalah yang kian bertambah dengan sistem manajemen file ClearCase kami, yang sering menolak untuk membiarkan saya menggunakan aktivitas build tertentu kecuali saya juga menyertakan aktivitas lain yang 'memiliki dependensi'.

Sekarang saya benar-benar akan maju dengan proses ini, saya bertanya-tanya apakah saya salah memahami seluruh tujuan menggunakan mesin build - dan karena kami hanya menggunakan mesin ini untuk penyebaran kode ke lingkungan Test, Staging dan Produksi kami, dan bukan untuk penerapan pengujian Pengembang pribadi kami, saya tidak yakin itu melayani tujuan apa pun.

Jadi, apa alasan sebenarnya untuk menggunakan mesin build, dan apakah saya bahkan sudah mendekati menggunakannya dengan benar?

Biasanya Anda tidak hanya memiliki mesin build khusus, tetapi juga menjalankan server build pada mesin khusus tersebut. Alat berat berdedikasi hanya menawarkan keuntungan karena tidak pernah menghalangi pekerjaan pengembang dan menggunakan mesin terpusat.

Server build menawarkan lebih banyak. Sebuah build sever memungkinkan untuk CI (integrasi berkelanjutan), yang berarti bahwa itu akan secara otomatis membangun pada setiap dorongan ke VCS Anda (seperti git), bahkan mungkin menjalankan tes unit jika Anda memilikinya dan memungkinkan untuk "penyebaran satu klik". Build server dapat memberi tahu Anda per email jika build atau tes gagal. Mereka menawarkan data historis dan tren tentang apa yang terjadi.

Bangun server umumnya dapat diakses oleh banyak pengguna atau tim sekaligus, dengan menggunakan web gui yang berjalan di browser.

Di dunia Java salah satu server build yang paling banyak digunakan adalah Jenkins. Jenkins bekerja dengan sangat baik dengan C ++ builds (Karena Anda tampaknya menggunakan kedua bahasa itu). Jenkins menyebut dirinya server otomatisasi, karena ia dapat menjalankan semua jenis tugas yang tidak harus terkait dengan pemrograman dan pembangunan.

Selain jawaban Traubenfuchs, Anda telah mengisyaratkan alasan lain untuk mesin pembuat dalam pertanyaan Anda.

Hanya karena perangkat lunak dibuat di mesin Anda , itu tidak berarti bahwa itu akan dibangun di atas milik orang lain. Anda mungkin mengandalkan beberapa file acak yang kebetulan berada di mesin Anda (dan bahkan mungkin tidak di bawah kontrol versi). Anda mungkin mengandalkan beberapa aplikasi atau pustaka yang terlupakan yang dipanggil dari skrip pembuatan yang tidak jelas.

Jika Anda memiliki mesin build khusus, Anda harus tahu apa yang diinstal di dalamnya. Ini harus didokumentasikan dengan baik. Jika ada kebutuhan untuk membangun kembali perangkat lunak, mungkin bertahun-tahun kemudian, seharusnya hanya diperlukan untuk membuat mesin build baru dengan hal-hal yang terdokumentasi terinstal di dalamnya.

Alasan utama memiliki mesin build khusus adalah untuk mendapatkan build yang konsisten terlepas dari siapa yang melakukan build. Workstation pengembang jarang (baca: tidak pernah) identik. Sulit untuk mengetahui bahwa setiap build menggunakan versi dependensi dan kompiler yang sama persis dll. Salah satu masalah terburuk dengan dev workstation build adalah pengembang dapat membangun dari kode yang tidak dicek ke dalam kontrol versi.

Tidak jelas platform / bahasa apa yang Anda gunakan, tetapi idealnya Anda harus memiliki server build yang menarik langsung dari kontrol sumber. Artinya, ketika membangun diperlukan, itu akan mengambil sumber dari versi repositori yang diberikan dan mengkompilasinya secara otomatis. Ini membutuhkan penggunaan alat build otomatis untuk membuat skrip build. Jika Anda tidak memiliki ini, itu harus menjadi langkah # 1.

Perlu diingat bahwa tidak ada yang salah dengan membangun secara lokal untuk pembangunan. Anda pasti harus bekerja dalam menjalankan unit test, analisis kualitas kode dan untuk mengasah skrip pembuatan. Kalau tidak, Anda akan membuang banyak waktu. Output dari server build adalah untuk apa pun yang Anda ingin pindahkan ke produksi. Semua aktivitas QA seperti pengujian integrasi dan penerimaan harus dilakukan hanya dengan build dari build server.

Jawaban lain dengan benar mencatat bahwa Anda harus mengotomatisasi pembuatan, yang berarti tidak perlu berjalan ke kantor lain. Namun, izinkan saya mengusulkan sejumlah langkah yang dapat Anda ambil untuk meningkatkan proses pembuatan Anda:

• Pertama, atur akses jarak jauh ke server build! Jika Anda membangun secara manual dengan mengetikkan perintah "make", ini berarti Anda tidak perlu lagi berjalan ke kantor lain untuk mengetik "make", Anda bisa langsung memasukkan SSH ke server build dan mengetik "make". Jika Anda belum menggunakan make atau sistem build yang serupa, gunakan sistem build seperti itu.
• Kedua, instal lingkungan integrasi berkelanjutan yang secara otomatis menarik perubahan terbaru dari sistem kontrol versi (Anda memiliki sistem kontrol versi, kan? Jika tidak, itu akan menjadi langkah tambahan) dan membangunnya. Saya merekomendasikan Jenkins. Siapkan Jenkins untuk menjalankan tes unit dan juga tes integrasi level sistem (Anda memiliki keduanya, bukan? Jika tidak, buat tes tersebut mulai dari tes unit dan kemudian berakhir dengan tes integrasi level sistem).
• Ketiga, jika Anda merasa berbagi mesin yang sama dengan tim lain bermasalah (seperti jika Anda memiliki pendapat berbeda tentang sistem operasi apa dan versi serta bittiness apa yang harus Anda gunakan), pertimbangkan untuk menggunakan virtualisasi. Server yang baik hari ini dapat menjalankan sejumlah besar mesin virtual. Mungkin Anda bisa membuat sendiri mesin 32-bit dan mesin 64-bit sehingga Anda tahu bangunannya bekerja pada kedua arsitektur.
• Terakhir, ini mungkin tidak diperlukan: jika Anda benar-benar harus memiliki mesin khusus, seperti jika kinerja aplikasi Anda sangat penting dan build / uji coba lainnya yang berjalan pada saat yang sama mempengaruhi hasil Anda terlalu banyak, instal server perangkat keras khusus daripada hanya Anda yang menggunakannya. Namun, pada server terbaru yang mungkin memiliki sebanyak 40 core CPU virtual atau lebih, relatif mudah untuk membuat beberapa mesin virtual yang tidak berbagi akses ke core CPU yang sama.

Saya akan menganggap mesin bersama jauh lebih baik daripada pembuatan manual. Proyek saya saat ini menggunakan mesin virtual sekarang, tetapi karena kebutuhan untuk tes kinerja integrasi tingkat sistem, kami pindah ke server khusus dengan 40 core CPU virtual yang memerlukan tes kinerja 17.

... alih-alih mendapatkan mesin yang sebenarnya di kantor kami untuk digunakan, kami harus berbagi satu mesin dengan beberapa grup lain ...

Anda mengatakan bahwa sepertinya itu adalah hal yang buruk.

Anda sekarang memiliki server build bersama yang dibangun oleh Anda semua - milik Anda dan tim lain -. Konsistensi membangun? Memeriksa.

... kerumitan harus meninggalkan kantor saya dengan semua informasi yang diperlukan dan kemudian berjalan menuruni tangga ke kantor lain hanya untuk melakukan pembangunan sederhana membuat saya bertanya-tanya mengapa saya pernah mengusulkan ini di tempat pertama.

Anda masih melakukan build secara manual dan itu tidak bagus.

Anda memerlukan proses server yang Anda kirim / antri permintaan untuk pembangunan harus dilakukan atas nama Anda dan minta proses itu mengirimkan kembali hasilnya.

Selain jawaban yang relevan lainnya, sepertinya Anda menjalankan build Anda langsung di mesin yang dimaksud.

Untuk sistem build yang andal, terutama saat berbagi mesin build dengan pengguna lain, itu normal untuk menjalankan build Anda dalam mesin virtual. Ini memastikan pengguna lain tidak dapat mengubah perilaku bangunan Anda dengan memasang versi aplikasi atau pustaka mereka sendiri yang menjadi sandaran kode Anda. Keuntungan besar dari ini adalah bahwa VM dapat dengan mudah didukung, dan juga dapat dengan mudah dikloning ke PC lain (termasuk mesin pengembangan Anda sendiri).

Ini memberikan lokasi terpusat, netral untuk melakukan pembangunan, terlepas dari konfigurasi IDE, OS, perpustakaan dari masing-masing pengembang.

Dengan mesin build khusus, Anda dapat membuatnya membangun kembali setiap kali ada dorongan kode ke repositori. Ketika seseorang merusak bangunan, proses dapat segera mengirimkan peringatan sehingga masalahnya dapat segera diperbaiki.

Selain membuat semuanya lebih berulang dan dapat diandalkan dan memastikan repositori tidak penuh dengan sampah yang rusak dengan masalah ketergantungan yang bersembunyi, itu membuat kehidupan para pengembang lebih mudah karena yang harus mereka lakukan untuk membuat bangunan bekerja di mesin mereka adalah menyalin apa pun sedang dilakukan pada mesin build.