Membangun otomatisasi vs menyebarkan otomatisasi vs integrasi berkelanjutan

Saya ingin menjadi lebih efisien dan saya ingin menggunakan alat ops secara efisien.

Dengan mengingat hal ini, saya ingin belajar lebih banyak tentang integrasi berkesinambungan, tetapi tampaknya ada banyak hal yang berbeda mengenai hal itu.

Saya benar-benar bekerja dengan setelan Jetbrains dalam pekerjaan saya (IntelliJ, WebStorm ...), jadi saya ingin terus menggunakannya, dan saya ingin menggunakan TeamCity yang tampaknya menjadi alat yang hebat dengan banyak plugin untuk integrasi berkesinambungan.

Masalah saya adalah saya tidak tahu apa perbedaan antara:

• membangun otomasi (TeamCity adalah perangkat lunak semacam ini): Saya tahu bahwa kita dapat membangun aplikasi kita dengan repositori VCS jarak jauh dan ini hebat, tetapi apa tujuan utamanya? Informasi apa yang penting saat melakukan ini? Bahkan, saya sudah tahu apakah perangkat lunak saya dibuat atau tidak secara lokal, dan rekan tim saya juga. Jadi, apa tujuan menggunakannya tanpa menggunakan otomatisasi?

• menggunakan otomatisasi (TeamCity tampaknya tidak melakukannya dengan mudah)

• integrasi berkelanjutan (yang tampaknya merupakan gabungan dari keduanya di atas)
• pengiriman terus menerus (apa ini sebenarnya? mengapa berbeda dari integrasi berkelanjutan?)

Bisakah Anda membantu saya untuk mengerti lebih banyak tentang ini?

Wikipedia memberikan ringkasan yang cukup bagus dari sebagian besar istilah ini. Inilah pendapat saya tentang mereka:

• Build automation mengotomatiskan bagaimana perangkat lunak dibangun alih-alih menggunakan kompiler secara manual. Ini akan dicapai melalui alat seperti misalnya Make atau Ant .

• Otomasi penyebaran mengambil perangkat lunak buatan Anda dan menyebarkan atau menginstalnya pada sistem pengujian atau produksi.

• Integrasi berkelanjutan berarti memiliki proses otomatis untuk membangun perangkat lunak Anda secara berkelanjutan saat pengembang memeriksa kode, dan menjalankan tes unit untuk memastikan kode tersebut masih berfungsi. Misalnya, setiap 15 hingga 30 menit server mungkin bangun, pindai VCS untuk check-in baru, lalu perbarui dan bangun proyek jika ada perubahan. Selain melakukan langkah kompilasi, ini juga merupakan peluang besar untuk menjalankan pengujian unit otomatis dan pemeriksaan kualitas kode .

• Pengiriman kontinu adalah kombinasi dari semua konsep sebelumnya di mana pembuatan perangkat lunak juga digunakan untuk sistem pengujian, secara opsional dengan pengujian yang dilakukan dan laporan yang dihasilkan.

Paling tidak, Anda harus memiliki otomatisasi pembuatan, yaitu semacam skrip pembuatan. Itu memungkinkan Anda untuk mengklik satu tombol atau mengeluarkan satu perintah untuk membangun proyek Anda. Manfaatnya adalah mengurangi kesalahan dari langkah-langkah yang berjalan secara manual. Lingkungan build yang kompleks mungkin melibatkan pembuatan kode (pikirkan DAO dari konfigurasi, kode antarmuka seperti JAXB ), kompilasi kode, pengemasan, penyesuaian metadata, dll. Dengan banyak hal yang perlu dilakukan, Anda memerlukan daftar periksa: mengapa tidak membuat daftar periksa menjadi: skrip build Anda, dan gunakan alat untuk menjalankannya? Ini mengurangi kesalahan dan memberikan konsistensi.

Selanjutnya adalah CI: ini benar - benar baik tetapi tidak sepenuhnya diperlukan. Ini membantu mengidentifikasi masalah awal. Jika Anda memiliki beberapa pengembang yang memeriksa kode sepanjang hari dan mungkin tidak menyinkronkan ruang kerja mereka sendiri terus-menerus, ada risiko bahwa perubahan mereka akan saling mengganggu. Saya merujuk khusus untuk kesalahan kode statis, bukan konflik kontrol versi. Server pembangun CI akan mengurangi risiko ini.

Akhirnya kami memiliki langkah penyebaran. Idenya di sini adalah untuk menghemat waktu dan mengurangi kesalahan dari penggunaan perangkat lunak secara manual. Sama seperti membangun otomatisasi, ada seratus cara untuk mengacaukan penyebaran perangkat lunak. Saya secara pribadi tinggal lembur di kantor untuk memperbaiki masalah penyebaran manual pada banyak kesempatan ketika kita membutuhkan sistem yang berfungsi untuk pelanggan yang datang di lokasi besok. Mengotomatiskan banyak sistem menimbulkan lebih banyak risiko: alih-alih satu sistem mungkin macet atau mengalami kesalahan aneh, kini kami memiliki banyaksistem yang bisa salah. Namun, risiko itu jauh lebih rendah daripada seseorang yang kehilangan langkah pada daftar periksa atau mengeluarkan perintah yang salah dan mengacaukan penyebaran. Jika Anda beruntung, Anda dapat dengan mudah mengembalikan cadangan DB dan memulai kembali, jika Anda beruntung kesalahan dapat menyebabkan sistem berfungsi dengan tidak benar. Apakah ini cacat perangkat lunak? Apakah teknisi tidak mengatur konfigurasi dengan benar? Ini membutuhkan waktu untuk mendiagnosis, waktu yang mungkin tidak Anda miliki dan waktu yang tidak perlu dikeluarkan jika Anda mengotomatiskan proses.

• Integrasi Berkelanjutan adalah praktik menggabungkan semua perubahan pengembang menjadi arus utama bersama beberapa kali sehari. Praktik ini sekarang sangat di mana-mana sehingga mungkin tidak tampak signifikan, namun secara tradisional tim akan bekerja pada perangkat lunak selama berminggu-minggu atau bahkan berbulan-bulan sendirian. Hasilnya adalah "Neraka Integrasi" ketika aliran pekerjaan yang terpisah digabungkan menjadi satu. Continuous Integration biasanya digunakan dengan build otomatis dari mainline bersama untuk menemukan masalah lebih awal, tetapi lebih banyak tentang seringnya komitmen dan alur kerja pengembang daripada tentang DevOps.

• Bangun otomatis bermanfaat untuk mengambil masalah yang mungkin menyebabkan build lulus secara lokal, tetapi gagal pada server build (mis. Anda lupa memeriksa file, dependensi pada server build tidak cocok). Memiliki build server mendeteksi masalah ini berarti Anda dapat memperbaikinya sebelum rekan kerja Anda melakukannya.

• Pengiriman Berkesinambungan melibatkan pengerahan, pengoperasian, dan pengujian perangkat lunak Anda secara terus-menerus. Sementara pembuatan otomatis memastikan perangkat lunak Anda benar-benar membangun (dan unit tes lulus), itu tidak berarti bahwa skrip penerapan Anda masih berfungsi atau bahwa perangkat lunak Anda benar-benar berjalan dari ujung ke ujung. Tujuan Pengiriman Berkelanjutan adalah untuk memiliki serangkaian pemeriksaan yang memastikan jalur utama tetap dalam kondisi yang sesuai untuk penyebaran ke produksi.

• Penerapan Berkelanjutan adalah langkah logis berikutnya - secara otomatis mengerahkan setiap komit yang berhasil melewati pipa pengiriman kontinu. Ada beberapa manfaat untuk praktik ini, tetapi bagi saya, gagasan utama di sini adalah bahwa komitmen kecil yang sering kurang berisiko.

Saya sarankan membaca buku ini untuk informasi lebih lanjut:

• Pengiriman Berkelanjutan: Rilis Perangkat Lunak Yang Andal Melalui Build, Test, dan Automation Deployment

Teamcity seperti banyak alat build hanyalah aplikasi pusat yang memungkinkan Anda menjalankan banyak tugas berbeda. Ini termasuk membangun seperti membangun CI, membangun rilis penuh dan memungkinkan Anda untuk melakukan penyebaran. Jika Anda menggunakan teamcity untuk memanggil semut atau tidak untuk menjalankan msbuild pada file solusi, Anda juga dapat memanggil skrip nant yang akan melakukan penyebaran. Mungkin memerlukan sedikit skrip tetapi tidak terlalu sulit.

Kami menggunakan teamcity dan bambu untuk CI penuh, CI Database dan menyebarkan ke lingkungan Integrasi. Kami kemudian menggunakan teamcity untuk pembuatan rilis lengkap dan membuat skrip migrasi db secara otomatis. Ini diperiksa ke dalam SVN melalui pekerjaan tim memanggil ke skrip asli. Untuk penyebaran, Anda dapat menebaknya, kami menggunakan teamcity untuk memanggil nant untuk melakukan tugas penggunaan. Ini berfungsi dengan baik karena agen teamcity berbicara ke server teamcity dan agen tersebut dapat ada di salah satu server di lokasi DMZ yang membantu memindahkan kode di luar firewall, dll. Jadi hanya teamcity atau bambu yang Anda butuhkan untuk menangani seluruh skenario .