Apa perbedaan antara ketiga istilah ini? Universitas saya memberikan definisi berikut:

Integrasi Berkelanjutan pada dasarnya hanya berarti bahwa copy pekerjaan pengembang disinkronkan dengan arus utama bersama beberapa kali sehari.

Pengiriman Berkelanjutan digambarkan sebagai evolusi logis dari integrasi berkelanjutan: Selalu dapat menempatkan produk ke dalam produksi!

Penerapan Berkelanjutan digambarkan sebagai langkah logis berikutnya setelah pengiriman kontinu: Secara otomatis menyebarkan produk ke dalam produksi setiap kali melewati QA!

Mereka juga memberikan peringatan: Kadang-kadang istilah "Penerapan Berkelanjutan" juga digunakan jika Anda dapat terus-menerus menyebar ke sistem pengujian.

Semua ini membuatku bingung. Setiap penjelasan yang sedikit lebih detail (atau disertai dengan contoh) sangat dihargai!

Integrasi berkelanjutan

Saya Setuju dengan definisi universitas Anda. Integrasi Kontinu adalah strategi untuk bagaimana pengembang dapat mengintegrasikan kode ke jalur utama secara terus menerus - berbeda dari yang sering.

Anda dapat mengklaim bahwa itu hanyalah strategi percabangan dalam sistem kontrol versi Anda.

Ini terkait dengan ukuran tugas yang Anda tetapkan untuk pengembang; Jika tugas diperkirakan memakan waktu 4-5 hari kerja maka pengembang tidak akan memiliki hasutan untuk memberikan apa pun untuk 4-5 hari ke depan, karena dia belum selesai dengan apa pun - belum.

Jadi ukuran penting:

small task = continuous integration
big task   = frequent integration

Ukuran tugas yang ideal tidak lebih besar dari pekerjaan sehari. Dengan cara ini pengembang secara alami akan memiliki setidaknya satu integrasi per hari.

Pengiriman terus menerus

Pada dasarnya ada tiga sekolah dalam Pengiriman Berkelanjutan:

Pengiriman Berkelanjutan adalah perpanjangan alami dari Integrasi Berkelanjutan

Sekolah ini, melihat seri tanda tangan Addison-Wesley "Martin Fowler" dan membuat asumsi bahwa sejak rilis 2007 disebut "Continuous Integration" dan yang mengikuti tahun 2011 disebut "Continuous Delivery" mereka mungkin volume 1 + 2 dari ide konseptual yang sama yang berkaitan dengan sesuatu yang berkelanjutan .

Pengiriman Berkelanjutan berkaitan dengan Pengembangan Perangkat Lunak Agile

Sekolah ini mengambil off-set dalam gagasan bahwa Pengiriman Berkelanjutan adalah semua tentang mampu mendukung prinsip-prinsip dalam gerakan gesit, bukan hanya sebagai ide konseptual atau letter of intent tetapi untuk nyata - dalam kehidupan nyata.

Mengambil offset dalam prinsip pertama dalam Agile Manifesto di mana istilah "pengiriman berkelanjutan" sebenarnya digunakan untuk pertama kalinya:

Prioritas tertinggi kami adalah untuk memuaskan pelanggan melalui pengiriman awal dan berkelanjutan dari perangkat lunak yang berharga.

Sekolah ini mengklaim bahwa "Pengiriman Berkelanjutan" adalah paradigma yang mencakup semua yang diperlukan untuk menerapkan verifikasi otomatis "definisi selesai" Anda .

Sekolah ini menerima bahwa "Pengiriman Berkelanjutan" dan kata buzz atau megatren "DevOps" adalah sisi lain dari koin yang sama, dalam arti bahwa mereka berdua mencoba merangkul atau merangkum paradigma atau pendekatan baru ini dan bukan hanya teknik.

Pengiriman Berkelanjutan adalah sinonim dengan Penerapan Berkelanjutan

Pendukung sekolah ketiga bahwa Penerapan Berkelanjutan dan Pengiriman Berkelanjutan dapat digunakan secara bergantian untuk mengartikan hal yang sama.

Ketika sesuatu sudah siap di tangan pengembang, itu segera dikirim ke pengguna akhir, yang dalam banyak kasus akan berarti bahwa itu harus digunakan untuk lingkungan produksi. Karenanya "Menyebarkan" dan "Memberikan" berarti sama.

Sekolah mana yang akan diikuti

Universitas Anda jelas bergabung dengan sekolah pertama dan mengklaim bahwa kami mengacu pada volume 1 + 2 dari seri publikasi yang sama. Pendapat saya adalah bahwa ini adalah penyalahgunaan istilah Pengiriman Berkelanjutan.

Saya pribadi menganjurkan untuk pemahaman bahwa Pengiriman Berkelanjutan terkait dengan menerapkan dukungan kehidupan nyata untuk ide dan konsep yang dinyatakan oleh gerakan gesit. Jadi saya bergabung dengan sekolah yang mengatakan istilah itu mencakup seluruh paradigma - seperti "DevOps".

Sekolah yang menggunakan pengiriman sebagai sinonim untuk digunakan sebagian besar didukung oleh vendor alat yang membuat konsol penempatan, mencoba untuk mendapatkan sedikit hype dari penggunaan istilah Continuous Delivery yang lebih luas .

Penerapan berkelanjutan

Fokus pada Penerapan Berkelanjutan sebagian besar relevan dalam domain di mana akses pengguna akhir ke pembaruan perangkat lunak bergantung pada pembaruan beberapa sumber terpusat untuk informasi ini dan di mana sumber terpusat ini tidak selalu mudah untuk diperbarui karena bersifat monolitik atau memiliki (juga) koherensi tinggi oleh alam (web, SOA, Database dll).

Untuk banyak domain yang menghasilkan perangkat lunak di mana tidak ada sumber informasi terpusat (perangkat, produk konsumen, instalasi klien, dll.) Atau di mana sumber tersentralisasi untuk informasi mudah diperbarui (app store sistem manajemen artefak, repositori Open Source, dll. ), hampir tidak ada hype tentang istilah Penerapan Berkelanjutan sama sekali. Mereka hanya mengerahkan; itu bukan hal besar - itu bukan rasa sakit yang membutuhkan fokus khusus.

Fakta bahwa Continuous Deployment bukanlah sesuatu yang secara umum menarik bagi semua orang juga merupakan argumen bahwa sekolah yang mengklaim bahwa "pengiriman" dan "penyebaran" adalah sinonim membuat semuanya salah. Karena Pengiriman Berkelanjutan sebenarnya sangat masuk akal bagi semua orang - bahkan jika Anda melakukan perangkat lunak yang disematkan dalam perangkat atau melepaskan plugin Open Source untuk suatu kerangka kerja.

Definisi universitas Anda bahwa Penerapan Berkelanjutan adalah langkah alami berikutnya dari Pengiriman Berkelanjutan secara implisit mengasumsikan bahwa setiap pengiriman yang QA'ed harus segera tersedia bagi pengguna akhir, lebih dekat dengan definisi yang digunakan suku saya untuk menggambarkan istilah "Berkelanjutan Release ", yang, pada gilirannya, adalah konsep lain yang secara umum juga tidak masuk akal bagi semua orang.

Rilis dapat menjadi hal yang sangat strategis atau politis dan tidak ada alasan untuk menganggap bahwa setiap orang ingin melakukan hal ini setiap saat (kecuali jika mereka adalah toko buku online, jenis perusahaan layanan streaming). Namun demikian, perusahaan yang tidak secara membabi buta melepaskan segala sesuatu sepanjang waktu mungkin memiliki sejumlah alasan mengapa mereka ingin menjadi penguasa penyebaran, jadi mereka juga melakukan Penempatan Berkelanjutan . Bukan rilis untuk produksi, tetapi kandidat rilis untuk lingkungan seperti produksi .

Sekali lagi saya yakin universitas Anda salah. Mereka salah mengartikan "Penyebaran Berkelanjutan" untuk "Pelepasan Berkelanjutan".

Penyebaran terus-menerus hanyalah disiplin untuk terus dapat memindahkan hasil dari proses pengembangan ke lingkungan seperti produksi di mana pengujian fungsional dapat dilaksanakan dalam skala penuh.

Alur Cerita Pengiriman Berkelanjutan

Dalam gambar itu semuanya menjadi hidup:

Proses Integrasi Berkelanjutan adalah dua tindakan pertama dalam diagram transisi-negara. yang - jika berhasil - memulai pipa Pengiriman Kontinu yang mengimplementasikan definisi selesai . Penempatan hanyalah salah satu dari banyak tindakan yang harus dilakukan terus menerus dalam pipa ini. Idealnya, proses diotomatisasi dari titik di mana pengembang berkomitmen ke VCS ke titik di mana pipa telah mengkonfirmasi bahwa kami memiliki kandidat rilis yang valid.

Baik pertanyaan maupun jawaban tidak cocok dengan cara berpikir sederhana saya tentang hal itu. Saya seorang konsultan dan telah menyinkronkan definisi-definisi ini dengan sejumlah tim Dev dan orang-orang DevOps, tetapi saya ingin tahu bagaimana ini cocok dengan industri pada umumnya:

Pada dasarnya saya memikirkan praktik lincah pengiriman terus-menerus seperti sebuah kontinum:

Tidak kontinu (semuanya manual) 0% ----> Pengiriman Nilai Berkelanjutan 100% (semuanya otomatis)

Langkah-langkah menuju pengiriman berkelanjutan:

Nol. Tidak ada yang otomatis ketika dev kode check in ... Anda beruntung jika mereka telah menyusun, menjalankan, atau melakukan pengujian apa pun sebelum check-in.

1. Continuous Build: build otomatis pada setiap check-in, yang merupakan langkah pertama, tetapi tidak melakukan apa pun untuk membuktikan integrasi fungsional kode baru.

2. Integrasi Berkelanjutan (CI): pembuatan otomatis dan pelaksanaan setidaknya unit test untuk membuktikan integrasi kode baru dengan kode yang ada, tetapi lebih disukai tes integrasi (end-to-end).

3. Penyebaran Berkelanjutan (CD): penyebaran otomatis ketika kode melewati CI setidaknya ke lingkungan pengujian, lebih disukai ke lingkungan yang lebih tinggi ketika kualitas terbukti baik melalui CI atau dengan menandai lingkungan yang lebih rendah sebagai LULUS setelah pengujian manual. IE, pengujian mungkin manual dalam beberapa kasus, tetapi mempromosikan ke lingkungan selanjutnya adalah otomatis.

4. Pengiriman Berkelanjutan: publikasi otomatis dan rilis sistem ke dalam produksi. Ini adalah CD menjadi produksi ditambah perubahan konfigurasi lainnya seperti pengaturan untuk pengujian A / B, pemberitahuan kepada pengguna fitur baru, memberitahukan dukungan versi baru dan mengubah catatan, dll.

EDIT: Saya ingin menunjukkan bahwa ada perbedaan antara konsep "pengiriman berkelanjutan" sebagaimana dirujuk dalam prinsip pertama Agile Manifesto ( http://agilemanifesto.org/principles.html ) dan praktik Pengiriman Berkelanjutan, seperti yang dirujuk oleh konteks pertanyaan. Prinsip pengiriman berkelanjutan adalah upaya untuk mengurangi limbah Inventaris seperti yang dijelaskan dalam Lean thinking ( http://www.miconleansixsigma.com/8-wastes.html ). Praktek Pengiriman Berkelanjutan (CD) oleh tim tangkas telah muncul dalam bertahun-tahun sejak Agile Manifesto ditulis pada tahun 2001. Praktik tangkas ini secara langsung membahas prinsip, meskipun mereka adalah hal yang berbeda dan tampaknya mudah membingungkan.

Saya pikir definisi amazon lurus dan mudah dimengerti.

" Pengiriman berkelanjutan adalah metodologi pengembangan perangkat lunak di mana proses rilis otomatis. Setiap perubahan perangkat lunak secara otomatis dibangun, diuji, dan digunakan untuk produksi. Sebelum dorongan akhir untuk produksi, seseorang, tes otomatis, atau aturan bisnis memutuskan kapan dorongan terakhir harus terjadi Meskipun setiap perubahan perangkat lunak yang berhasil dapat segera dirilis ke produksi dengan pengiriman terus menerus, tidak semua perubahan harus segera dilepaskan.

Integrasi berkelanjutan adalah praktik pengembangan perangkat lunak di mana anggota tim menggunakan sistem kontrol versi dan mengintegrasikan pekerjaan mereka sering ke lokasi yang sama, seperti cabang utama. Setiap perubahan dibuat dan diverifikasi oleh pengujian dan verifikasi lain untuk mendeteksi kesalahan integrasi secepat mungkin. Integrasi berkelanjutan difokuskan pada pembuatan dan pengujian kode secara otomatis, dibandingkan dengan pengiriman berkelanjutan, yang mengotomatiskan seluruh proses rilis perangkat lunak hingga produksi . "

Silakan periksa http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Atlassian memposting penjelasan yang baik tentang integrasi berkelanjutan vs pengiriman berkelanjutan vs penyebaran berkelanjutan .

Pendeknya:

Continuous Integration - adalah otomatisasi untuk membangun dan menguji aplikasi setiap kali komit baru didorong ke cabang.

Continuous Delivery - adalah Continuous Integration + Deploy aplikasi ke produksi dengan "mengklik tombol" (Rilis ke pelanggan sering, tetapi sesuai permintaan).

Penyebaran Berkelanjutan - adalah Pengiriman Berkelanjutan tetapi tanpa campur tangan manusia (Rilis kepada pelanggan sedang berlangsung).

Integrasi Berkelanjutan pada dasarnya hanya berarti bahwa copy pekerjaan pengembang disinkronkan dengan arus utama bersama beberapa kali sehari.

Atau lebih dari beberapa kali per hari. Seringkali setiap tugas diskrit yang diberikan diselesaikan, pada dasarnya. Misalnya, pertimbangkan tim pengembang yang mengerjakan satu aplikasi bisnis. Di banyak lingkungan, hal berikut ini dapat terjadi:

• Satu atau dua pengembang menyimpan perubahan lokal selama beberapa hari karena "belum siap".
• Satu atau dua pengembang membuat cabang di kontrol sumber sehingga mereka dapat bekerja pada fitur mereka "tanpa terganggu oleh perubahan orang lain".

Ini dapat menyebabkan masalah. Kode / tugas organisasi yang buruk menyebabkan percabangan, percabangan mengarah pada penggabungan, penggabungan ... mengarah pada penderitaan. Integrasi berkelanjutan sebagai praktik mengatasi hal ini dengan mendorong semua orang untuk bekerja dari sumber yang sama. Item pekerjaan individual harus cukup terpisah untuk diselesaikan dalam waktu singkat (paling banyak jam).

Pada dasarnya ide umumnya adalah mengintegrasikan perubahan kecil dalam sejumlah kecil pekerjaan. Mengintegrasikan perubahan besar adalah jumlah pekerjaan yang tidak proporsional. Agregat pekerjaan integrasi lebih kecil jika dilakukan dalam langkah-langkah kecil yang konstan. Hal ini memungkinkan pengembang untuk menghabiskan lebih banyak waktu bekerja pada fitur yang terlihat oleh bisnis alih-alih overhead proses pengembangan.

Pengiriman Berkelanjutan digambarkan sebagai evolusi logis dari integrasi berkelanjutan: Selalu dapat menempatkan produk ke dalam produksi!

Ini mengikuti ide yang sama dari item pekerjaan yang diskrit dan terdefinisi dengan baik. Jika ada basis kode induk tunggal yang hanya pernah disesuaikan dalam penambahan kecil dengan fitur kerja yang lengkap, teruji, diketahui maka basis kode itu selalu stabil. Pengujian otomatis adalah kunci di sini untuk dapat membuktikan stabilitas dengan menekan sebuah tombol.

Semakin sedikit pekerjaan stabilisasi yang perlu dilakukan (yang, sekali lagi, adalah proses pengembangan overhead dan harus dihilangkan), semakin sering basis kode dapat didorong ke lingkungan tertentu. Di banyak perusahaan penyebaran bisa menjadi proses yang sangat melelahkan. Bahkan operasi all-on-deck selama seminggu. Ini mahal dan tidak menghasilkan nilai bisnis. Dengan menggunakan definisi item pekerjaan yang baik, pengujian otomatis yang efektif, dan integrasi berkesinambungan tim dapat berada dalam posisi untuk mengotomatiskan pengiriman basis kode ke lingkungan tertentu.

Penerapan Berkelanjutan digambarkan sebagai langkah logis berikutnya setelah pengiriman kontinu: Secara otomatis menyebarkan produk ke dalam produksi setiap kali melewati QA!

Anda jarang akan melihat ini terjadi di lingkungan bisnis, dan itu sangat menyenangkan ketika ditemui. Jika basis kode dapat secara otomatis diuji dan secara otomatis digunakan untuk lingkungan tertentu, maka, produksi adalah lingkungan seperti yang lain. Jadi jika tim telah membangun sampai titik ini maka ada potensi nilai yang signifikan untuk bisnis dengan selalu dapat menyebarkan pembaruan untuk produksi.

Perbaikan yang cacat dikirim ke pelanggan dengan lebih cepat, fitur-fitur baru mencapai pasar lebih cepat, ide-ide baru diuji terhadap pasar dengan peningkatan yang lebih kecil untuk memungkinkan pengalihan prioritas, dll.

Sebagai contoh, katakanlah sebuah perusahaan memiliki ide besar untuk fitur baru dalam produk atau layanan berbasis perangkat lunak mereka. Mereka telah melakukan beberapa penelitian, mereka tahu pasar, dan mereka percaya ide ini akan menghasilkan garis pendapatan baru yang kuat. Sekarang pertimbangkan dua opsi untuk menghadirkan fitur itu:

1. Habiskan waktu berbulan-bulan untuk mengembangkan semuanya dalam satu cabang. Habiskan berminggu-minggu untuk mengintegrasikannya kembali ke basis kode utama. Habiskan beberapa hari untuk mengujinya. Habiskan satu hari untuk menyebarkannya. Dan baru kemudian mulai melacak pendapatan aktual dalam sistem produksi.
2. Terapkan sebagian kecil fitur, satu per satu. Setiap minggu lepaskan sepotong baru. Setiap minggu dapatkan lebih banyak data tentang pendapatan aktual.

Dalam skenario pertama, jika fitur tersebut tidak memiliki efek pasar yang diinginkan, maka banyak uang yang terbuang untuk sesuatu yang sebenarnya tidak diinginkan pelanggan. Dalam skenario kedua, fakta bahwa pelanggan tidak menginginkannya ditentukan jauh, jauh lebih awal dan sisa pekerjaan tidak diprioritaskan.

Pada akhirnya "hal-hal yang berkelanjutan" ini adalah tentang menghilangkan overhead proses pembangunan. Jika garis pendapatan perusahaan adalah penawaran layanan tertentu maka idealnya semua biaya mereka harus masuk ke penawaran itu. Overhead proses pengembangan (penggabungan kode, pengujian ulang fitur yang sama setelah penggabungan, tugas penerapan manual, dll.) Tidak benar-benar berkontribusi pada nilai layanan, sehingga konsep-konsep ini berupaya menghilangkan biaya-biaya tersebut dari proses.

Satu grafik dapat menggantikan banyak kata:

Nikmati! :-)

# Saya telah memperbarui gambar yang benar ...

Perbedaan antara Continuous Integration, Continuous delivery, dan Deployment berkelanjutan

Saya pikir kita terlalu menganalisis dan mungkin sedikit menyulitkan rangkaian kata "berkelanjutan". Dalam konteks ini kontinu berarti otomatisasi. Untuk kata lain yang dilampirkan pada "terus menerus" gunakan bahasa Inggris sebagai panduan terjemahan Anda dan tolong jangan mencoba untuk mempersulit! Dalam "pembangunan berkelanjutan" kita secara otomatis membangun (tulis / kompilasi / tautan / dll) aplikasi kita menjadi sesuatu yang dapat dieksekusi untuk platform / wadah / runtime / etc tertentu. "Integrasi berkelanjutan" berarti fungsionalitas baru Anda menguji dan berkinerja sebagaimana dimaksud saat berinteraksi dengan entitas lain. Jelas, sebelum integrasi terjadi, pembangunan harus terjadi dan pengujian menyeluruh juga akan digunakan untuk memvalidasi integrasi. Jadi, dalam "integrasi berkelanjutan" seseorang menggunakan otomasi untuk menambah nilai pada sekumpulan fungsionalitas yang ada dengan cara yang tidak secara negatif mengganggu fungsionalitas yang ada tetapi lebih terintegrasi dengan baik, menambahkan nilai yang dirasakan ke keseluruhan. Integrasi menyiratkan, dengan definisi bahasa Inggrisnya saja, bahwa hal-hal berjalan secara harmonis sehingga dalam pembicaraan kode saya menambahkan kompilasi, tautan, tes dan berjalan dengan sempurna di dalam keseluruhan. Anda tidak akan menyebut sesuatu yang terintegrasi jika gagal produk akhirnya, kan ?! Dalam konteks kami "Penerapan berkelanjutan" identik dengan "pengiriman kontinu" karena pada akhirnya kami telah memberikan fungsionalitas kepada pelanggan kami. Namun, dengan menganalisis hal ini secara berlebihan, saya dapat berpendapat bahwa penggunaan adalah bagian dari pengiriman karena menggunakan sesuatu tidak selalu berarti bahwa kami mengirimkannya. Kami menyebarkan kode tetapi karena kami belum Agar tidak dikomunikasikan secara efektif kepada para pemangku kepentingan, kami gagal menghasilkan dari perspektif bisnis! Kami mengerahkan pasukan, tetapi kami belum mengirimkan air dan makanan yang dijanjikan ke kota terdekat. Bagaimana jika saya menambahkan istilah "transisi berkelanjutan", apakah ia memiliki kelebihannya sendiri? Lagi pula, mungkin lebih cocok untuk menggambarkan pergerakan kode melalui lingkungan karena memiliki konotasi "dari / ke" lebih dari penyebaran atau pengiriman yang bisa menyiratkan satu lokasi saja, selamanya! Ini yang kita dapatkan jika kita tidak menerapkan akal sehat. apakah itu akan memiliki kelebihannya sendiri? Lagi pula, mungkin lebih cocok untuk menggambarkan pergerakan kode melalui lingkungan karena memiliki konotasi "dari / ke" lebih dari penyebaran atau pengiriman yang bisa menyiratkan satu lokasi saja, selamanya! Ini yang kita dapatkan jika kita tidak menerapkan akal sehat. apakah itu akan memiliki kelebihannya sendiri? Lagi pula, mungkin lebih cocok untuk menggambarkan pergerakan kode melalui lingkungan karena memiliki konotasi "dari / ke" lebih dari penyebaran atau pengiriman yang bisa menyiratkan satu lokasi saja, selamanya! Ini yang kita dapatkan jika kita tidak menerapkan akal sehat.

Kesimpulannya, ini adalah hal-hal sederhana untuk dijelaskan (melakukannya sedikit lebih ... rumit!), Cukup gunakan akal sehat, bahasa Inggris dan Anda akan baik-baik saja.

Integrasi Berkelanjutan: Praktek menggabungkan pekerjaan pengembangan dengan cabang utama terus-menerus sehingga kode telah diuji sesering mungkin untuk menangkap masalah lebih awal.

Pengiriman Berkelanjutan: Pengiriman kode terus-menerus ke suatu lingkungan setelah kode siap dikirim. Ini bisa menjadi pementasan atau produksi. Idenya adalah produk dikirim ke basis pengguna, yang dapat QA atau pelanggan untuk ditinjau dan diperiksa.

Uji unit selama fase Integrasi Berkelanjutan tidak dapat menangkap semua bug dan logika bisnis, terutama masalah desain yang mengapa kita membutuhkan QA, atau lingkungan pementasan untuk pengujian.

Penerapan Berkelanjutan: Penempatan atau pelepasan kode segera setelah siap. Penerapan Berkelanjutan membutuhkan Integrasi dan Pengiriman Berkelanjutan jika tidak, kualitas kode tidak akan dijamin dalam rilis.

Penerapan Berkelanjutan ~~ Integrasi Berkelanjutan + Pengiriman Berkelanjutan

Integrasi berkelanjutan

• Otomatis (pembuatan check in + unit test)

Pengiriman terus menerus

• Integrasi berkelanjutan
• Otomatis (penerapan untuk menguji lingkungan + pengujian beban + uji integrasi)
• Manual (penyebaran ke produksi)

Penerapan berkelanjutan

• Pengiriman Berkelanjutan tetapi otomatis (penyebaran ke produksi)

CI / CD adalah sebuah perjalanan. Bukan tujuan.

Tahapan ini adalah saran. Anda dapat menyesuaikan tahapan berdasarkan kebutuhan bisnis Anda. Beberapa tahap dapat diulang untuk beberapa jenis pengujian, keamanan, dan kinerja. Bergantung pada kompleksitas proyek Anda dan struktur tim Anda, beberapa tahapan dapat diulang beberapa kali di level yang berbeda. Misalnya, produk akhir dari satu tim dapat menjadi ketergantungan dalam proyek tim berikutnya. Ini berarti bahwa produk akhir tim pertama kemudian dipentaskan sebagai artefak dalam proyek tim berikutnya.

Catatan kaki:

Berlatih Integrasi Berkelanjutan dan Pengiriman Berkelanjutan di AWS

Sumber: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Apa itu Integrasi Berkelanjutan Integrasi Kontinu adalah proses atau praktik pengembangan uji coba otomatis dan pengujian otomatis, misalnya, pengembang diwajibkan untuk memasukkan kode-nya beberapa kali ke dalam repositori bersama di mana setiap integrasi diverifikasi oleh uji coba membangun otomatis.

Jika build gagal / berhasil, ia diberitahukan ke pengembang dan kemudian ia dapat mengambil tindakan yang relevan.

Apa itu Pengiriman Berkelanjutan Kontinu adalah praktik di mana kami menjaga kode kami dapat digunakan pada titik mana pun yang telah lulus semua tes dan memiliki semua konfigurasi yang diperlukan untuk mendorong kode ke produksi tetapi belum digunakan.

Apa itu Penerapan Berkelanjutan Dengan bantuan CI, kami telah membuat build untuk aplikasi kami dan siap untuk berproduksi. Pada langkah ini build kami siap dan dengan CD kami dapat menyebarkan aplikasi kami langsung ke lingkungan QA dan jika semuanya berjalan dengan baik kami dapat menggunakan build yang sama untuk produksi.

Jadi pada dasarnya, penyebaran berkelanjutan adalah satu langkah lebih maju dari pengiriman berkelanjutan. Dengan praktik ini, setiap perubahan yang melewati semua tahapan pipa produksi Anda dilepaskan ke pelanggan Anda.

Penyebaran Berkelanjutan adalah kombinasi dari Manajemen Konfigurasi dan Kontainerisasi.

Manajemen Konfigurasi: CM adalah tentang menjaga konfigurasi server yang akan kompatibel dengan persyaratan aplikasi.

Kontainerisasi : Kontainerisasi adalah seperangkat tol yang akan menjaga konsistensi di seluruh lingkungan.

Sumber img: https://www.atlassian.com/

DevOps adalah kombinasi dari 3C - kontinu , komunikasi , kolaborasi dan ini mengarah pada fokus utama di berbagai industri.

Dalam dunia perangkat yang terhubung dengan IoT, banyak fitur scrum seperti pemilik produk, web, seluler, dan QA yang bekerja dengan gesit dalam scrum siklus scrum untuk mengirimkan produk ke pelanggan akhir.

Integrasi berkelanjutan: Fitur multiple scrum bekerja secara simultan di beberapa titik akhir

Pengiriman terus menerus: Dengan integrasi dan penyebaran, pengiriman produk ke beberapa pelanggan harus ditangani pada saat yang sama.

Penerapan berkelanjutan: banyak produk yang digunakan untuk beberapa pelanggan di berbagai platform.

Tonton ini untuk mengetahui bagaimana DevOps mengaktifkan dunia yang terhubung IoT: https://youtu.be/nAfZt2t4HqA

Dari apa yang saya pelajari dengan Alex Cowan dalam kursus Continuous Delivery & DevOps , CI dan CD adalah bagian dari pipa produk yang terdiri dari waktu dari Pengamatan ke Produk yang Dirilis.

Dari Pengamatan ke Desain tujuannya adalah untuk mendapatkan ide yang dapat diuji kualitas tinggi. Bagian dari proses ini dianggap sebagai Desain Berkelanjutan .

Apa yang terjadi setelahnya, ketika kita beralih dari Kode dan seterusnya, itu dianggap sebagai kemampuan Pengiriman Berkelanjutan yang tujuannya adalah untuk mengeksekusi ide-ide dan rilis kepada pelanggan dengan sangat cepat (Anda dapat membaca buku Jez Humble pengiriman Berkelanjutan: Perangkat Lunak yang Andal Melepaskan melalui Build, Test, dan Otomatisasi Penyebaran untuk lebih jelasnya). Pipa berikut menjelaskan langkah-langkah yang terdiri dari Integrasi Berkelanjutan (CI) dan Pengiriman Berkelanjutan (CD).

Integrasi berkelanjutan , sebagaimana dijelaskan oleh Mattias Petter Johansson ,

adalah ketika tim perangkat lunak memiliki kebiasaan melakukan beberapa penggabungan per hari dan mereka memiliki sistem verifikasi otomatis untuk memeriksa masalah tersebut.

(Anda dapat menonton dua video berikut untuk tinjauan umum yang lebih praktis menggunakan CircleCI - Memulai dengan CircleCI - P2 Integrasi Berkelanjutan dan Menjalankan CircleCI berdasarkan Permintaan Tarik ).

Seseorang dapat menentukan pipa CI / CD sebagai berikut, yang beralih dari Kode Baru ke Produk yang dirilis.

Tiga langkah pertama harus dilakukan dengan Tes, memperluas batas dari apa yang diuji.

Penerapan berkelanjutan , di sisi lain, adalah untuk menangani Penyebaran secara otomatis. Jadi, setiap komit kode yang melewati fase pengujian otomatis secara otomatis dilepaskan ke dalam produksi.

Catatan : Ini tidak harus seperti apa seharusnya saluran pipa Anda, namun mereka dapat berfungsi sebagai referensi.

mari kita singkat:

CI: Praktek pengembangan perangkat lunak di mana anggota tim mengintegrasikan pekerjaan mereka setidaknya setiap hari. Setiap integrasi diverifikasi oleh build otomatis (termasuk tes) untuk mendeteksi kesalahan secepat mungkin. CD: CD Dibangun di atas CI, tempat Anda membuat perangkat lunak sedemikian rupa sehingga perangkat lunak dapat dirilis kapan saja.