DevOps

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Mantra favorit konsultan perangkat lunak adalah menjawab "Itu tergantung" pada pertanyaan apa pun yang diajukan. Ini bukan karena konsultan perangkat lunak suka tidak mengambil posisi. Ini karena tidak ada jawaban yang benar untuk pertanyaan apa pun dalam perangkat lunak. Tidak ada hak mutlak dan salah, melainkan keseimbangan antara berlawanan.

Misalnya, dua sekolah utama pengembangan aplikasi web: Aplikasi Halaman Tunggal (SPAs) versus aplikasi sisi server. Di satu sisi, pengalaman pengguna cenderung lebih baik dengan SPAs dan jumlah lalu lintas ke server web dapat diminimalkan sehingga memungkinkan untuk menghosting mereka pada sesuatu yang sesederhana hosting statis. Di sisi lain, SPAs cenderung lebih lambat untuk berkembang dan lebih sulit untuk diuji. Manakah pilihan yang tepat? Itu tergantung pada situasimu.

Aplikasi cloud-native tidak kebal terhadap dikotomi yang sama. Mereka memiliki keuntungan yang jelas dalam hal kecepatan pengembangan, stabilitas, dan skalabilitas, tetapi mengelolanya bisa sedikit lebih sulit.

Bertahun-tahun yang lalu, tidak jarang proses pemindahan aplikasi dari pengembangan ke produksi memakan waktu satu bulan, atau bahkan lebih. Perusahaan merilis perangkat lunak pada irama 6 bulan atau bahkan setiap tahun. Seseorang hanya perlu melihat Microsoft Windows untuk mendapatkan gambaran tentang ritme rilis yang diterima sebelum masa pembaruan terus-menerus di Windows 10. Lima tahun berlalu antara Windows XP dan Vista, tiga lebih lanjut antara Vista dan Windows 7.

Sekarang sudah cukup dikenal bahwa mampu merilis perangkat lunak dengan cepat memberikan perusahaan yang bergerak cepat keuntungan pasar yang besar dibandingkan dengan pesaing mereka yang bergerak lambat. Itulah alasan mengapa pembaruan besar untuk Windows 10 sekarang dilakukan kira-kira setiap enam bulan sekali.

Pola dan praktik yang memungkinkan rilis yang lebih cepat dan lebih andal untuk memberikan nilai kepada bisnis secara kolektif dikenal sebagai DevOps. Mereka terdiri dari berbagai ide yang mencakup seluruh siklus hidup pengembangan perangkat lunak dari menentukan aplikasi hingga memberikan dan mengoperasikan aplikasi tersebut.

DevOps muncul sebelum microservices dan kemungkinan pergerakan menuju layanan yang lebih kecil dan lebih sesuai untuk tujuan tidak akan mungkin dilakukan tanpa DevOps untuk membuat merilis dan pengoperasian banyak aplikasi lebih mudah dalam produksi.

Gambar 10-1 - DevOps dan layanan mikro.

Melalui praktik DevOps yang baik, dimungkinkan untuk mewujudkan keuntungan aplikasi cloud-native tanpa terbebani oleh segunung pekerjaan yang terkait dengan pengoperasian aplikasi.

Tidak ada palu emas ketika datang ke DevOps. Tidak ada yang dapat menjual solusi lengkap dan lengkap untuk merilis dan mengoperasikan aplikasi berkualitas tinggi. Ini karena setiap aplikasi sangat berbeda dari yang lain. Namun, ada alat yang dapat membuat DevOps menjadi proposisi yang jauh lebih tidak menakutkan. Salah satu alat ini dikenal sebagai Azure DevOps.

Azure DevOps

Azure DevOps memiliki sejarah panjang. Ini dapat melacak akarnya kembali ke ketika Team Foundation Server pertama kali pindah online dan melalui berbagai perubahan nama: Visual Studio Online dan Visual Studio Team Services. Namun, selama bertahun-tahun, itu telah menjadi jauh lebih dari pendahulunya.

Azure DevOps dibagi menjadi lima komponen utama:

Gambar 10-2 - Azure DevOps.

Azure Repos - Manajemen kode sumber yang mendukung Team Foundation Version Control (TFVC) dan Git favorit industri. Permintaan pull menyediakan cara untuk memungkinkan kolaborasi sosial dalam pengembangan kode dengan menumbuhkan diskusi tentang perubahan saat dilakukan.

Azure Boards - Menyediakan alat pelacakan masalah dan item kerja yang berupaya memungkinkan pengguna memilih alur kerja yang paling sesuai untuk mereka. Muncul dengan sejumlah templat yang telah dikonfigurasi sebelumnya termasuk templat untuk mendukung gaya pengembangan SCRUM dan Kanban.

Azure Pipelines - Sistem manajemen build dan rilis yang mendukung integrasi ketat dengan Azure. Build dapat dijalankan di berbagai platform dari Windows ke Linux ke macOS. Agen build dapat disediakan di cloud atau lokal.

Paket Pengujian Azure - Tidak ada orang QA yang akan tertinggal dengan manajemen pengujian dan dukungan pengujian eksplorasi yang ditawarkan oleh fitur Paket Pengujian.

Azure Artifacts - Umpan artefak yang memungkinkan perusahaan untuk membuat versi internal mereka sendiri dari NuGet, npm, dan lainnya. Ini melayani tujuan ganda untuk bertindak sebagai cache paket hulu jika ada kegagalan repositori terpusat.

Unit organisasi tingkat atas di Azure DevOps dikenal sebagai Proyek. Dalam setiap proyek, berbagai komponen, seperti Azure Artifacts, dapat diaktifkan dan dinonaktifkan. Masing-masing komponen ini memberikan keuntungan yang berbeda untuk aplikasi cloud-native. Tiga yang paling berguna adalah repositori, papan, dan alur. Jika pengguna ingin mengelola kode sumber mereka di tumpukan repositori lain, seperti GitHub, tetapi masih memanfaatkan Azure Pipelines dan komponen lainnya, itu sangat mungkin.

Untungnya, tim pengembangan memiliki banyak opsi saat memilih repositori. Salah satunya adalah GitHub.

Tindakan GitHub

Didirikan pada tahun 2009, GitHub adalah repositori berbasis web yang sangat populer untuk menghosting proyek, dokumentasi, dan kode. Banyak perusahaan teknologi besar, seperti Apple, Amazon, Google, dan perusahaan mainstream menggunakan GitHub. GitHub menggunakan sistem kontrol versi terdistribusi sumber terbuka bernama Git sebagai fondasinya. Di atasnya, ia kemudian menambahkan serangkaian fiturnya sendiri, termasuk pelacakan cacat, permintaan fitur dan pull, manajemen tugas, dan wiki untuk setiap basis kode.

Seiring berkembangnya GitHub, GitHub juga menambahkan fitur DevOps. Misalnya, GitHub memiliki alur integrasi berkelanjutan/pengiriman berkelanjutan (CI/CD) sendiri, yang disebut GitHub Actions. GitHub Actions adalah alat otomatisasi alur kerja yang didukung komunitas. Ini memungkinkan tim DevOps berintegrasi dengan alat yang ada, mencampur dan mencocokkan produk baru, dan menghubungkan ke siklus hidup perangkat lunak mereka, termasuk mitra CI/CD yang ada."

GitHub memiliki lebih dari 40 juta pengguna, menjadikannya host kode sumber terbesar di dunia. Pada bulan Oktober 2018, Microsoft membeli GitHub. Microsoft telah berjanji bahwa GitHub akan tetap menjadi platform terbuka yang dapat dicolokkan dan diperluas pengembang mana pun. Perusahaan ini terus beroperasi sebagai perusahaan independen. GitHub menawarkan paket untuk akun perusahaan, tim, profesional, dan gratis.

Kontrol sumber

Mengatur kode untuk aplikasi cloud-native bisa menjadi tantangan. Alih-alih satu aplikasi raksasa, aplikasi cloud-native cenderung terdiri dari web aplikasi yang lebih kecil yang berbicara satu sama lain. Seperti halnya semua hal dalam komputasi, pengaturan kode terbaik tetap menjadi pertanyaan terbuka. Ada contoh aplikasi yang berhasil menggunakan berbagai jenis tata letak, tetapi dua varian tampaknya memiliki popularitas paling populer.

Sebelum turun ke kontrol sumber aktual itu sendiri, mungkin perlu memutuskan berapa banyak proyek yang sesuai. Dalam satu proyek, ada dukungan untuk beberapa repositori, dan membangun alur. Meskipun papan proyek sedikit lebih rumit, tugas tetap dapat ditetapkan dengan mudah ke beberapa tim dalam satu proyek. Dimungkinkan untuk mendukung ratusan, bahkan ribuan pengembang, dari satu proyek Azure DevOps. Melakukannya kemungkinan adalah pendekatan terbaik karena menyediakan satu tempat bagi semua pengembang untuk bekerja dan mengurangi kebingungan menemukan bahwa satu aplikasi ketika pengembang tidak yakin di mana proyek tempatnya berada.

Memisahkan kode untuk layanan mikro dalam proyek Azure DevOps bisa sedikit lebih menantang.

Gambar 10-3 - Satu vs. banyak repositori.

Repositori untuk layanan mikro

Sekilas, pendekatan ini tampaknya seperti pendekatan paling logis untuk memisahkan kode sumber untuk layanan mikro. Setiap repositori dapat berisi kode yang diperlukan untuk membangun satu layanan mikro. Keuntungan dari pendekatan ini mudah terlihat:

1. Instruksi untuk membangun dan memelihara aplikasi dapat ditambahkan ke file README di akar setiap repositori. Saat menelusuri repositori, instruksi ini mudah ditemukan, sehingga mengurangi waktu persiapan bagi pengembang.
2. Setiap layanan terletak di tempat yang logis, mudah ditemukan dengan mengetahui nama layanan.
3. Build dapat dengan mudah disiapkan sehingga hanya dipicu ketika perubahan dilakukan pada repositori yang dimiliki.
4. Jumlah perubahan yang masuk ke repositori terbatas pada sejumlah kecil pengembang yang mengerjakan proyek.
5. Keamanan mudah disiapkan dengan membatasi repositori tempat pengembang memiliki izin baca dan tulis.
6. Pengaturan tingkat repositori dapat diubah oleh tim pemilik dengan minimal diskusi dengan orang lain.

Salah satu ide utama di balik layanan mikro adalah bahwa layanan harus diisolasi dan dipisahkan satu sama lain. Saat menggunakan Domain Driven Design untuk memutuskan batas layanan, layanan bertindak sebagai batas transaksional. Pembaruan database tidak boleh mencakup beberapa layanan. Kumpulan data terkait ini disebut sebagai konteks terikat. Ide ini tercermin oleh isolasi data layanan mikro ke database yang terpisah dan otonom dari layanan lainnya. Sangat masuk akal untuk membawa ide ini sampai ke kode sumber.

Namun, pendekatan ini bukan tanpa masalahnya. Salah satu masalah pengembangan yang lebih gnar di masa kita adalah mengelola dependensi. Pertimbangkan jumlah file yang membentuk direktori rata-rata node_modules . Instalasi baru dari sesuatu seperti create-react-app kemungkinan membawa ribuan paket. Pertanyaan tentang cara mengelola dependensi ini adalah yang sulit.

Jika dependensi diperbarui, maka paket hilir juga harus memperbarui dependensi ini. Sayangnya, karena membutuhkan pekerjaan pengembangan, node_modules direktori biasanya berakhir dengan beberapa versi dari satu paket, yang masing-masing merupakan dependensi dari beberapa paket lain yang dipasang dengan jadwal versi yang sedikit berbeda. Saat menyebarkan aplikasi, versi dependensi mana yang harus digunakan? Versi yang saat ini sedang diproduksi? Versi yang saat ini berada di Beta tetapi kemungkinan akan berada dalam produksi pada saat konsumen memasuki tahap produksi. Masalah sulit yang tidak diselesaikan hanya dengan menggunakan layanan mikro.

Ada pustaka yang bergantung pada berbagai proyek. Dengan membagi mikroservis menjadi satu per repositori, dependensi internal dapat diselesaikan secara optimal dengan menggunakan repositori internal, Azure Artifacts. Build untuk pustaka akan mendorong versi terbarunya ke Azure Artifacts untuk konsumsi internal. Proyek hilir masih harus diperbarui secara manual untuk mengadopsi ketergantungan pada paket yang telah diperbarui.

Kerugian lain hadir dengan sendirinya saat memindahkan kode antar layanan. Meskipun akan menyenangkan untuk percaya bahwa pembagian pertama aplikasi ke dalam layanan mikro adalah 100% benar, kenyataannya adalah bahwa jarang kita memiliki pandangan jauh ke depan untuk sepenuhnya menghindari kesalahan pembagian layanan. Dengan demikian, fungsionalitas dan kode yang mendorongnya perlu berpindah dari layanan ke layanan: repositori ke repositori. Ketika melompat dari satu repositori ke repositori lain, kode kehilangan riwayatnya. Ada banyak kasus, terutama jika terjadi audit, di mana memiliki riwayat penuh pada sepotong kode sangat berharga.

Kelemahan terakhir dan yang paling penting adalah mengoordinasikan perubahan. Dalam aplikasi layanan mikro sejati, seharusnya tidak ada dependensi penyebaran antar layanan. Harus dimungkinkan untuk menyebarkan layanan A, B, dan C dalam urutan apa pun karena mereka memiliki kopling longgar. Namun, pada kenyataannya, ada kalanya perubahan diperlukan untuk melibatkan beberapa repositori secara bersamaan. Beberapa contoh termasuk memperbarui pustaka untuk menutup lubang keamanan atau mengubah protokol komunikasi yang digunakan oleh semua layanan.

Untuk melakukan perubahan lintas repositori, diperlukan commit pada setiap repositori yang dilakukan secara berturut-turut. Setiap perubahan di setiap repositori harus diminta tarik dan ditinjau secara terpisah. Aktivitas ini bisa sulit untuk dikoordinasikan.

Alternatif untuk menggunakan banyak repositori adalah menempatkan semua kode sumber bersama-sama dalam repositori tunggal raksasa, yang semuanya diketahui.

Repositori tunggal

Dalam pendekatan ini, terkadang disebut sebagai monorepositori, semua kode sumber untuk setiap layanan dimasukkan ke dalam repositori yang sama. Pada awalnya, pendekatan ini tampaknya seperti ide yang buruk yang mungkin membuat berurusan dengan kode sumber menjadi sulit. Namun, ada beberapa kelebihan tertentu dalam bekerja dengan cara ini.

Keuntungan pertama adalah lebih mudah untuk mengelola dependensi antar proyek. Alih-alih mengandalkan beberapa umpan artefak eksternal, proyek dapat langsung mengimpor satu sama lain. Ini berarti bahwa pembaruan bersifat instan, dan versi yang bertentangan kemungkinan akan ditemukan pada waktu kompilasi di stasiun kerja pengembang. Akibatnya, menggeser beberapa pengujian integrasi ke kiri.

Saat memindahkan kode antar proyek, sekarang lebih mudah untuk mempertahankan riwayat karena file akan terdeteksi telah dipindahkan daripada ditulis ulang.

Keuntungan lainnya adalah bahwa perubahan yang luas dan beragam yang melintasi batas layanan dapat dilakukan dalam satu commit. Aktivitas ini mengurangi beban kerja karena adanya puluhan perubahan yang harus ditinjau secara satu per satu.

Ada banyak alat yang dapat melakukan analisis kode statis untuk mendeteksi praktik pemrograman yang tidak aman atau penggunaan API yang bermasalah. Di dunia multi-repositori, setiap repositori perlu diulang untuk menemukan masalah di dalamnya. Repositori tunggal memungkinkan menjalankan analisis semua di satu tempat.

Ada juga banyak kelemahan pada pendekatan repositori tunggal. Salah satu yang paling mengkhawatirkan adalah memiliki satu repositori menimbulkan masalah keamanan. Jika konten repositori bocor dalam repositori per model layanan, jumlah kode yang hilang minimal. Dengan satu repositori, semua yang dimiliki perusahaan bisa hilang. Ada banyak contoh di masa lalu tentang kejadian ini yang mengacaukan seluruh upaya pengembangan permainan. Memiliki beberapa repositori mengekspos lebih sedikit area permukaan, yang merupakan sifat yang diinginkan di sebagian besar praktik keamanan.

Ukuran repositori tunggal kemungkinan menjadi tidak dapat dikelola dengan cepat. Ini menyajikan beberapa implikasi performa yang menarik. Mungkin perlu menggunakan alat khusus seperti Virtual File System untuk Git, yang awalnya dirancang untuk meningkatkan pengalaman bagi pengembang di tim Windows.

Sering kali argumen untuk menggunakan satu repositori berujung pada argumen bahwa Facebook atau Google menggunakan metode ini untuk penataan kode sumber. Jika pendekatannya cukup baik untuk perusahaan-perusahaan ini, maka, tentu saja, itu adalah pendekatan yang benar untuk semua perusahaan. Faktanya adalah hanya sedikit perusahaan yang beroperasi dengan skala yang mendekati Facebook atau Google. Masalah yang terjadi pada skala tersebut berbeda dari yang akan dihadapi sebagian besar pengembang. Apa yang baik untuk angsa betina mungkin tidak baik untuk angsa jantan.

Pada akhirnya, salah satu solusi dapat digunakan untuk menghosting kode sumber untuk layanan mikro. Namun, dalam kebanyakan kasus, pengeluaran manajemen dan pengeluaran rekayasa untuk beroperasi dalam satu repositori tidak sebanding dengan keuntungan yang sedikit. Memisahkan kode melalui beberapa repositori mendorong pemisahan kekhawatiran yang lebih baik dan mendorong otonomi di antara tim pengembangan.

Struktur direktori standar

Terlepas dari debat tentang penggunaan satu atau beberapa repositori, setiap layanan akan memiliki direktori sendiri. Salah satu pengoptimalan terbaik untuk memungkinkan pengembang menyeberang antar proyek dengan cepat adalah mempertahankan struktur direktori standar.

Gambar 10-4 - Struktur direktori standar.

Setiap kali proyek baru dibuat, templat yang menempatkan struktur yang benar harus digunakan. Templat ini juga dapat menyertakan item yang berguna seperti file README dasar dan azure-pipelines.yml. Dalam arsitektur layanan mikro apa pun, tingkat varians yang tinggi antara proyek membuat operasi massal terhadap layanan lebih sulit.

Ada banyak alat yang dapat menyediakan templat untuk seluruh direktori, yang berisi beberapa direktori kode sumber. Yeoman populer di dunia JavaScript dan GitHub baru-baru ini merilis Templat Repositori, yang menyediakan banyak fungsionalitas yang sama.

Manajemen tugas

Mengelola tugas dalam proyek apa pun bisa sulit. Di muka ada banyak pertanyaan yang harus dijawab tentang jenis alur kerja yang akan disiapkan untuk memastikan produktivitas pengembang yang optimal.

Aplikasi cloud-native cenderung lebih kecil daripada produk perangkat lunak tradisional atau setidaknya dibagi menjadi layanan yang lebih kecil. Pelacakan masalah atau tugas yang terkait dengan layanan ini tetap sama pentingnya dengan proyek perangkat lunak lainnya. Tidak ada yang ingin kehilangan jejak beberapa item kerja atau menjelaskan kepada pelanggan bahwa masalah mereka tidak dicatat dengan benar. Papan dikonfigurasi pada tingkat proyek, namun dalam setiap proyek, bagian dapat ditentukan. Ini memungkinkan pemecahan masalah menjadi beberapa komponen. Keuntungan untuk menjaga semua pekerjaan untuk seluruh aplikasi di satu tempat adalah mudah untuk memindahkan item kerja dari satu tim ke tim lain karena mereka dipahami lebih baik.

Azure DevOps dilengkapi dengan sejumlah templat populer yang telah dikonfigurasi sebelumnya. Dalam konfigurasi paling dasar, yang perlu diketahui adalah apa yang ada di backlog, apa yang sedang dikerjakan orang, dan apa yang sudah selesai. Penting untuk memiliki visibilitas ini ke dalam proses membangun perangkat lunak, sehingga pekerjaan dapat diprioritaskan dan menyelesaikan tugas yang dilaporkan kepada pelanggan. Tentu saja, beberapa proyek perangkat lunak tetap berpegang pada proses sesingkat to do, , doingdan done. Tidak perlu waktu lama bagi orang untuk mulai menambahkan langkah-langkah seperti QA atau Detailed Specification ke proses.

Salah satu bagian yang lebih penting dari metodologi Agile adalah introspeksi diri secara berkala. Ulasan ini dimaksudkan untuk memberikan wawasan tentang masalah apa yang dihadapi tim dan bagaimana mereka dapat ditingkatkan. Sering kali, ini berarti mengubah alur masalah dan fitur melalui proses pengembangan. Oleh karena itu, sangat wajar untuk memperbesar tata letak papan dengan tahapan tambahan.

Tahapan di papan bukan satu-satunya alat organisasi. Bergantung pada konfigurasi papan, ada hierarki item kerja. Item paling terperinci yang dapat muncul di papan adalah tugas. Secara default, tugas berisi bidang untuk judul, deskripsi, prioritas, perkiraan jumlah pekerjaan yang tersisa, dan kemampuan untuk menghubungkan dengan item pekerjaan atau pengembangan lainnya (cabang, commits, permintaan pull, builds, dan sebagainya). Item kerja dapat diklasifikasikan ke dalam berbagai area aplikasi dan perulangan (sprint) yang berbeda untuk membuatnya lebih mudah ditemukan.

Gambar 10-5 - Pekerjaan di Azure DevOps.

Bidang deskripsi mendukung gaya normal yang Anda harapkan (tebal, miring, garis bawah, dan coret) serta kemampuan untuk menyisipkan gambar. Ini menjadikannya alat yang kuat untuk digunakan saat menentukan tugas atau masalah.

Tugas dapat digulung menjadi fitur, yang menentukan unit kerja yang lebih besar. Fitur, pada gilirannya, dapat digulung menjadi epik. Mengklasifikasikan tugas dalam hierarki ini membuatnya jauh lebih mudah untuk memahami seberapa dekat fitur besar untuk diluncurkan.

Gambar 10-6 - Item kerja di Azure DevOps.

Ada berbagai jenis pandangan terhadap isu di Azure Boards. Item yang belum dijadwalkan muncul di backlog. Setelah itu, mereka dapat dialokasikan ke dalam sprint. Sprint adalah periode waktu terbatas di mana diharapkan sejumlah pekerjaan akan diselesaikan. Pekerjaan ini dapat mencakup tugas tetapi juga resolusi tiket. Sesampainya di sana, seluruh sprint dapat dikelola dari bagian papan Sprint. Tampilan ini menunjukkan bagaimana pekerjaan sedang berlangsung dan menyertakan bagan burn down untuk memberikan perkiraan yang terus diperbarui tentang apakah sprint akan berhasil.

Gambar 10-7 - Board di Azure DevOps.

Sekarang, harus jelas bahwa ada banyak kekuatan di Papan di Azure DevOps. Bagi pengembang, ada pandangan mudah tentang apa yang sedang dikerjakan. Bagi manajer proyek, ada wawasan tentang pekerjaan yang akan datang serta gambaran umum pekerjaan yang sedang berjalan. Untuk manajer, ada banyak laporan tentang resourcing dan kapasitas. Sayangnya, tidak ada yang ajaib tentang aplikasi cloud-native yang menghilangkan kebutuhan untuk melacak pekerjaan. Tetapi jika Anda harus melacak pekerjaan, ada beberapa tempat di mana pengalamannya lebih baik daripada di Azure DevOps.

Jalur CI/CD

Hampir tidak ada perubahan dalam siklus hidup pengembangan perangkat lunak yang begitu revolusioner karena munculnya integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD). Membangun dan menjalankan pengujian otomatis terhadap kode sumber proyek segera setelah perubahan dimasukkan untuk menangkap kesalahan lebih awal. Sebelum ada build integrasi berkelanjutan, tidak jarang ketika menarik kode dari repositori, ditemukan bahwa kode tersebut tidak lulus pengujian atau bahkan tidak dapat dibuat ulang. Hal ini mengakibatkan pelacakan sumber kerusakan.

Secara tradisional mengirim perangkat lunak ke lingkungan produksi memerlukan dokumentasi yang luas dan daftar langkah. Masing-masing langkah ini perlu diselesaikan secara manual dalam proses yang sangat rawan kesalahan.

Gambar 10-8 - Daftar Periksa.

Mitra dari integrasi berkelanjutan adalah distribusi berkelanjutan di mana paket baru disebarkan ke lingkungan. Proses manual tidak dapat menskalakan agar sesuai dengan kecepatan pengembangan sehingga otomatisasi menjadi lebih penting. Daftar periksa digantikan oleh skrip yang dapat menjalankan tugas yang sama lebih cepat dan lebih akurat daripada manusia mana pun.

Lingkungan tempat pengiriman berkelanjutan dikirimkan mungkin merupakan lingkungan pengujian atau, seperti yang sedang dilakukan oleh banyak perusahaan teknologi besar, itu bisa menjadi lingkungan produksi. Yang terakhir membutuhkan investasi dalam pengujian berkualitas tinggi yang dapat memberikan keyakinan bahwa perubahan tidak akan merusak produksi bagi pengguna. Dengan cara yang sama integrasi berkelanjutan menangkap masalah dalam kode lebih awal, pengiriman berkelanjutan menangkap masalah dalam proses penyebaran lebih awal.

Pentingnya mengotomatiskan proses build dan pengiriman diaksenuasi oleh aplikasi cloud-native. Penyebaran terjadi lebih sering dan ke lebih banyak lingkungan sehingga melakukan penyebaran secara manual menjadi hampir mustahil.

Azure Builds

Azure DevOps menyediakan serangkaian alat untuk membuat integrasi dan penyebaran berkelanjutan lebih mudah dari sebelumnya. Alat-alat ini terletak di bawah Azure Pipelines. Yang pertama adalah Azure Builds, yang merupakan alat untuk menjalankan definisi build berbasis YAML dalam skala besar. Pengguna dapat membawa mesin build mereka sendiri (bagus jika build memerlukan lingkungan yang disiapkan dengan cermat) atau menggunakan mesin dari kumpulan mesin virtual yang dihosting di Azure dan selalu diperbarui. Agen build yang dihosting ini telah diinstal sebelumnya dengan berbagai alat pengembangan tidak hanya untuk pengembangan .NET tetapi untuk segala sesuatu mulai dari pengembangan Java hingga Python hingga iPhone.

DevOps mencakup berbagai pengaturan pembangunan praktis yang dapat disesuaikan untuk berbagai jenis pembangunan. Definisi build didefinisikan dalam file yang disebut azure-pipelines.yml dan diperiksa ke repositori sehingga dapat di-versi bersama dengan kode sumber. Ini membuatnya jauh lebih mudah untuk membuat perubahan pada alur build di cabang karena perubahan dapat diperiksa ke cabang itu saja. Contoh azure-pipelines.yml untuk membangun aplikasi web ASP.NET pada kerangka kerja lengkap ditampilkan di Gambar 10-9.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

Gambar 10-9 - Sampel azure-pipelines.yml

Definisi penyusunan ini menggunakan sejumlah tugas bawaan yang membuat penyusunan semudah membangun set Lego (lebih sederhana dibanding set Millennium Falcon yang berukuran raksasa). Misalnya, tugas NuGet memulihkan paket NuGet, sementara tugas VSBuild memanggil alat build Visual Studio untuk melakukan kompilasi aktual. Ada ratusan tugas berbeda yang tersedia di Azure DevOps, dengan ribuan lainnya yang dikelola oleh komunitas. Kemungkinan apa pun jenis tugas penyusunan yang ingin Anda jalankan, seseorang mungkin telah membuatnya.

Build dapat dipicu secara manual, dengan check-in, sesuai jadwal, atau dengan menyelesaikan build lain. Dalam kebanyakan kasus, membangun setiap check-in diinginkan. Pembangunan dapat difilter sehingga pembangunan yang berbeda berjalan pada berbagai bagian repositori atau pada cabang yang berbeda. Ini memungkinkan skenario seperti menjalankan pembuatan yang cepat dengan pengurangan pengujian pada permintaan tarik dan menjalankan rangkaian regresi penuh terhadap cabang utama setiap malam.

Hasil akhir build adalah kumpulan file yang dikenal sebagai artefak pembangunan. Artefak ini dapat diteruskan ke langkah berikutnya dalam proses build atau ditambahkan ke umpan Azure Artifacts, sehingga dapat dikonsumsi oleh build lain.

Azure DevOps Rilis Terbaru

Build mengurus kompilasi perangkat lunak ke dalam paket yang dapat dikirim, tetapi artefak masih perlu didorong ke lingkungan pengujian untuk menyelesaikan pengiriman berkelanjutan. Untuk ini, Azure DevOps menggunakan alat terpisah yang disebut Rilis. Alat Rilis menggunakan pustaka tugas yang sama yang tersedia untuk Build tetapi memperkenalkan konsep "tahapan". Tahap adalah lingkungan terisolasi tempat paket diinstal. Misalnya, produk dapat menggunakan pengembangan, QA, dan lingkungan produksi. Kode terus dikirimkan ke lingkungan pengembangan di mana pengujian otomatis dapat dijalankan terhadapnya. Setelah pengujian tersebut lulus, rilis bergerak ke lingkungan QA untuk pengujian manual. Akhirnya, kode didorong ke lingkungan produksi di mana kode tersebut dapat dilihat oleh semua orang.

Gambar 10-10 - Alur rilis

Setiap tahap dalam build dapat secara otomatis dipicu oleh penyelesaian fase sebelumnya. Namun, dalam banyak kasus, ini tidak diinginkan. Memindahkan kode ke produksi mungkin memerlukan persetujuan dari seseorang. Alat Rilis mendukung ini dengan mengizinkan pemberi persetujuan di setiap langkah alur rilis. Aturan dapat disiapkan sehingga orang atau sekelompok orang tertentu harus menyetujui rilis sebelum masuk ke produksi. Gerbang ini memungkinkan pemeriksaan kualitas manual dan juga untuk kepatuhan terhadap persyaratan regulasi yang terkait dengan mengendalikan apa yang diproduksi.

Semua orang mendapatkan alur build

Tidak ada biaya untuk mengonfigurasi banyak alur build, jadi menguntungkan untuk memiliki setidaknya satu alur build per layanan mikro. Idealnya, layanan mikro dapat disebarkan secara independen ke lingkungan apa pun sehingga masing-masing dapat dilepaskan melalui alurnya sendiri tanpa merilis massa kode yang tidak terkait sempurna. Setiap alur dapat memiliki serangkaian persetujuannya sendiri yang memungkinkan variasi dalam proses build untuk setiap layanan.

Rilis penerapan versi

Salah satu kelemahan menggunakan fungsi Rilis adalah bahwa fungsi ini tidak dapat ditetapkan dalam file yang dicentang azure-pipelines.yml. Ada banyak alasan Anda mungkin ingin melakukannya dari memiliki definisi rilis per cabang hingga menyertakan kerangka rilis dalam templat proyek Anda. Untungnya, pekerjaan sedang berlangsung untuk mengalihkan beberapa tahap dukungan ke komponen Build. Ini akan dikenal sebagai build multi-tahap dan versi pertama tersedia sekarang!

SebelumnyaBerikutnya