💎 👨🏿‍🌾 👡 Pembaruan Proses CI / CD: teamcity 😾 🏨 🎦

Ini adalah artikel kedua dalam seri tentang memperbarui proses CI / CD. Sampai saat itu, persiapan sedang dilakukan untuk menyiapkan alat-alat baru, yaitu: perencanaan, rapat umum harian, menyelesaikan perselisihan, secara umum, semua tanpa itu tidak mungkin untuk secara kompeten membangun proses kerja. Dan sekarang, semua masalah telah diselesaikan, kami yakin bahwa kami dapat melanjutkan pengembangan, dan kode kami tidak akan tenggelam ke dalam lubang hitam dengan awal musim panas.

Biarkan saya mengingatkan Anda daftar isi daftar artikel, serta hasil singkat dari bagian sebelumnya.

Bagian 1: apa itu, mengapa tidak seperti, perencanaan, sedikit bash. Saya akan menyebut bagian ini hampir teknis.
Bagian 2: teamcity.
Bagian 3: penyebaran gurita.
Bagian 4: di belakang layar. Momen tidak menyenangkan, rencanakan masa depan, mungkin juga FAQ. Kemungkinan besar, itu juga bisa disebut dekat-teknis.

Kami memberi pelanggan konsep bukti dari sistem pengiriman pembaruan yang baru, mengidentifikasi kekurangan dari sistem yang ada, memilih dasar untuk yang baru, membuat rencana transisi, dan mengubah repositori lincah kami menjadi git. Juga, pada bagian sebelumnya, kami menjelaskan fitur-fitur proyek yang akan mempengaruhi seluruh proses selanjutnya.

Seperti disebutkan sebelumnya, solusi yang ada tidak memenuhi persyaratan modern. Awalnya, kemungkinan besar, satu build dikonfigurasikan dalam ccnet. Bangunan pertama yang memulai semuanya (seperti big bang, yeah). Kemudian, tampaknya, orang yang mengatur semuanya, menekan ctrl + c, ctrl + v, mengoreksi beberapa baris, dan menerima konfigurasi baru. Dan untuk semua waktu berikutnya, ini dilakukan dalam jumlah yang cukup sehingga kode sumber pada server build memakan lebih dari 60G. Dan ini hanya sumbernya! Dan ada log, buat artefak, file sementara, dan sebagainya. Hanya ini yang membuat saya berpikir. Melihat sistem yang lama, orang dapat melihat yang berikut: langkah build dilakukan untuk setiap modul. Bahkan, inti yang sama sudah dirakit. Dan rakitan ini disimpan untuk setiap modul (bersama dengan sumber) di server.Hasil pembangunan (90% identik) didorong ke repositori lokal (penyebaran git), dan juga, tentu saja, mengambil tempat mereka. Itu mungkin dan perlu untuk meninggalkan ini.

Pengaturan Umum

Pada tahap ini, diasumsikan bahwa sudah ada tim yang terkonfigurasi dan gurita. Pada tahap instalasi dan konfigurasi, kami tidak berhenti secara detail. Untuk kenyamanan, kami menuliskan url dan api-token dari gurita di tim env, yang, omong-omong, untuk proyek root terlihat seperti ini:

gambar

env.apiUserName dan env.apiUserPassword adalah akses api ke pengguna teamcity (akan diperlukan nanti), env.buildPath dan env .sourcePath - path default ke file build dan source, masing-masing, env.octoApiKey dan env.octoUrl - token dan url dari gurita. Mereka masih env.teamcityUrl menambahkan. Baiklah, env.tt.exe- jalur ke utilitas transformasi teks. Utilitas ini menghasilkan semua konfigurasi.

Dari plugin pihak ketiga, hanya integrasi Octopus Deploy yang diinstal.

Agar tidak membebani jumlah teks yang sudah sangat besar, hanya langkah-langkah di mana ada sesuatu yang layak diperhatikan akan diperiksa secara rinci. Diasumsikan bahwa segala sesuatu yang lain dapat dimengerti berdasarkan data yang disajikan dan pengetahuan pembaca. Bagaimanapun, jika Anda memiliki pertanyaan, saya akan dengan senang hati menjawabnya.

Rincian proyek, versi, nama

Hasilnya adalah skema proyek (seperti gambar, karena ada masalah dengan menampilkan daftar multilevel):
gambar

Kami akan membuat versi paket-paket sebagai berikut: major.minor.patch, di mana major sejauh ini 1, minor adalah build build dari konfigurasi Build, patch adalah counter build untuk konfigurasi Menyebarkan (tidak diperlukan untuk konfigurasi Bangun, karena itu selalu 0).

Catatan: versi lama dijelaskan di sini. Kami sedang mendesain ulang sehingga didasarkan pada tag git.

gambar

Sebagai contoh, di sini 1 adalah mayor, 95 minor, dan 1 adalah patch.

Dalam proses baru untuk modul akan ada satu build yang kemudian akan digunakan untuk setiap modul. Artinya, kode sumber disimpan dalam satu salinan untuk setiap lingkungan, hasil build juga, karena itu umum untuk semua modul. Konfigurasi dan pustaka unik dikemas dalam satu paket pada tahap penyebaran. Ini secara efektif akan menggunakan ruang disk dan mengurangi waktu pengiriman setiap paket.

Pada tahap persiapan, ada pertemuan singkat terpisah tentang konvensi penamaan file konfigurasi. Dulu (itu hanya), tetapi tidak selalu sama. Selain itu, nama konfigurasi tidak selalu mengandung informasi yang cukup. Akibatnya, semua nama konfigurasi adalah sebagai berikut:
ConfigurationType.Environment.ModName.configdi mana ConfigurationType dapat berupa AppSettings, Web, dll. Lingkungan - pengembangan, pengujian, pementasan, produksi. ModName adalah nama unik dari modul.

Modul

Semua proyek Modul bekerja dengan prinsip yang sama.

Setiap lingkungan memiliki konfigurasi Build yang:

Melakukan pengembalian nuget (Penginstal NuGet, pengembalian nuget)
Menghasilkan konfigurasi (Baris Perintah, transformasi teks)
Solusi buildit (Visual studio sln)
Mengambil file dari env.buildPath di zip dan mendorongnya ke gurita (Octopus deploy: push packages)
Rilis pembuatan (tidak ada penyebaran) (Octopus deploy membuat rilis)
Mereset versi tambalan (PowerShell)

Ada juga menggunakan konfigurasi yang bekerja berdasarkan pada templat dan lakukan hal berikut:

Mengambil konfigurasi yang dihasilkan pada tahap build (langkah 2) (Octopus menyebarkan paket push)
Menyebarkan rilis inti (yang dibuat pada langkah 6 dari build) (Octopus deploy: deploy release)
Rilis penyebaran individu (yang dibuat pada langkah 1 dari konfigurasi saat ini) (Octopus deploy: deploy rilis)
Menampilkan daftar semua domain untuk modul ini dalam log (langkah untuk kenyamanan penguji dan pengembang). (Powershell).

Untuk setiap konfigurasi penggunaan, konfigurasi pembangunan ditambahkan ke dependensi. Ini memungkinkan untuk meluncurkan build secara otomatis ketika digunakan jika tidak relevan, serta kemampuan untuk mereset versi patch.

Konfigurasi deploy_all. Sebenarnya, ini adalah rantai build yang menjelaskan bahwa Anda harus menjalankan build terlebih dahulu jika tidak relevan, dan kemudian menginstal semua mode secara bersamaan.

Ini terlihat seperti ini:

gambar

Mari kita lihat beberapa langkah dengan lebih detail.

Pengaturan Build.General

Dari yang tidak biasa hanya membangun format angka. Akan dijelaskan nanti.

Build.env

Yang menarik di sini adalah: env.coreProjectName - ditetapkan untuk seluruh proyek. Diperlukan untuk mengidentifikasi proyek di gurita.
env.Environment - ditetapkan untuk proyek Modul. Penting untuk memilih konfigurasi yang benar tergantung pada lingkungan.
env.octoChannel - saluran dalam gurita tempat paket itu jatuh. Sama seperti env.Environment .
env.serviceName adalah nama solusinya. Pada dasarnya, variabel ditambahkan untuk memudahkan visualisasi.
env.tenantRoleTag - tag penyewa di gurita. Lebih detail di bagian gurita.

Bangun.4

Tambahkan ke arsip dengan nama % env.serviceName%.% Build.number% .zip file dari direktori dengan hasil build, tidak termasuk semua konfigurasi, dan lain-lain dari folder bin / asli. Yang terakhir secara manual ditambahkan ke server web sekali dan tidak ada yang akan menyentuhnya lagi. Jika perlu, mereka juga akan diperbarui secara manual (untuk ini direncanakan untuk menulis skrip terpisah, tetapi kami akan jujur). Hal ini disebabkan oleh fakta bahwa perpustakaan-perpustakaan ini "dipegang" oleh kumpulan IIS, dan untuk penyebaran yang sukses itu harus dihentikan dan kemudian diluncurkan, yang membutuhkan waktu. Dengan mengecualikan pustaka ini dari penyebaran, kita dapat melewati langkah menghentikan kumpulan, yang akan mengurangi waktu penyebaran, dan, dengan demikian, downtime.

Bangun.5

Saya pikir semuanya jelas di sini, kecuali mengapa bidang Lingkungan kosong. Dalam paket apa yang didapat, gurita membuat keputusan berdasarkan tag pra-rilis (dikonfigurasi dalam saluran). Tag ini terkandung dalam % build.number% (stage-yang sama di layar dalam Build.General). Jadi dalam hal ini ternyata lebih nyaman. Juga patut memperhatikan kotak centang "Tampilkan proses penyebaran" . Jika tidak diinstal, timsity menganggap build berhasil segera setelah gurita telah memulai (tetapi belum selesai!) Pekerjaan. Yaitu, jika kotak centang tidak diinstal dan ada yang salah selama fase penerapan - tanpa melihat antarmuka gurita, kami tidak akan mengetahuinya.

Bangun.6

Tidak ada yang aneh, hanya skrip PowerShell dan informasi dari dokumentasi teamcity.

$pair = "%env.apiUserName%:%env.apiUserPassword%"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$depUri="%env.teamcityUrl%/app/rest/buildTypes?locator=snapshotDependency:(from:(build:(id:%teamcity.build.id%)),includeInitial:false)"
# Get all dependencies of main build
$result = (Invoke-RestMethod -Headers @{'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $depUri)
foreach ($i in $result.buildTypes.buildType.Count) { $buildId += $result.buildTypes.buildType.id }
$buildId = $buildId | Where-Object { $_ -ne 'Module_DeployAll' }
# Reset all child build counters to 1. This build counters are patch versions in every build. (1.build.patch)
for ($i=0; $i -lt $buildId.Count; $i++) {
  $buildCounterUri = "%env.teamcityUrl%/httpAuth/app/rest/buildTypes/"+$buildId[$i]+"/settings/buildNumberCounter"
  Invoke-RestMethod -Method Put -Headers @{'accept'='text/plain'; 'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $buildCounterUri -ContentType "text/plain" -Body 1
}

Di sini kita membutuhkan pengguna api di teamcity (env dibuat untuknya). Kami masuk, mengambil semua konfigurasi yang bergantung pada konfigurasi Build, dan mereset counter build mereka ke 1. Artinya, untuk setiap versi patch, ini merupakan indikator berapa kali build yang sama digunakan untuk modul tertentu. Jika tidak ada 1, itu berarti ada masalah dengan proses penempatan atau pengerjaan modul pada versi saat ini, dan membutuhkan perhatian.

Menyebarkan. Umum

Format versi: 1.% dep.Module_Build.build.counter%.% Build.counter% -staging , di mana
% dep.Module_Build.build.counter% adalah variabel sistem tim yang nilainya sesuai dengan konter build dari konfigurasi Build yang sesuai (harus ditambahkan ke dependensi). Faktanya, di sini 1 adalah versi utama, % dep.Module_Build.build.counter% minor, dan % build.counter% adalah patch. pementasan adalah tag pra-rilis.

Sebarkan

Saat menambahkan modul baru, hanya konfigurasi untuk penyebarannya yang ditambahkan dan nilai variabel env.modName diindikasikan . Semua variabel lain diwarisi dari proyek induk. Variabel env.tenantModTag untuk gurita dibentuk dari env.modName .

Menyebarkan.2

Menyebarkan paket inti.

Nomor rilis terbaru - gunakan rilis terbaru yang tersedia untuk lingkungan ini.
Tag penyewa - tag klien / organisasi. Lebih detail di bagian gurita.
Parameter cli tambahan. Di sini kami menunjukkan saluran di mana paket kami akan jatuh, serta parameter tambahan. Ini juga akan dibahas secara terpisah di bagian gurita.

Menyebarkan.3

Seperti Deploy.2, hanya paket modul individual yang digunakan.

Menyebarkan.4

Langkah ini juga akan dijelaskan secara rinci di bawah ini, karena menerima data dari gurita.

Konfigurasi untuk situs web Perusahaan dan modul Khusus dibangun di atas prinsip yang sama, dan poin utama di dalamnya adalah sama, jadi saya tidak melihat titik untuk menggambarkannya dalam detail yang sama. Mereka adalah satu, mereka tidak harus digunakan berkali-kali, dan sebenarnya ada nuget restore, transformasi teks, msbuild, push gurita, gurita membuat rilis + penyebaran.

Pelajari lebih lanjut tentang konfigurasi unik. Untuk beberapa mod, mungkin tidak ada lingkungan (misalnya, pementasan), mereka harus dikerahkan ke server lain, atau Anda harus secara manual mengatur pengidentifikasi klien (mengambil konfigurasi dasar dan mengubah beberapa bidang di dalamnya menggunakan PowerShell). Artinya, mereka bekerja dengan prinsip yang sama dengan modul utama. Keunikan mereka terletak pada kenyataan bahwa langkah-langkah ditambahkan / diubah untuk mereka, atau server penempatan diubah dan mereka tidak sesuai dengan templat, sehingga dibutuhkan sedikit lebih lama untuk membuatnya. Untungnya, ada beberapa dari mereka.

Teamcity: Ringkasan

Implementasi teamcity memungkinkan pendekatan yang lebih optimal untuk proses perakitan aplikasi. Sekarang ini membutuhkan waktu jauh lebih sedikit: alih-alih membangun kode yang sama setiap kali, kita membangunnya sekali. Kami juga memanfaatkan ruang disk, lalu lintas jaringan, dan waktu komputasi dengan lebih baik. Sebelumnya, jumlah paket untuk penyebaran (repositori dengan artefak) sama dengan jumlah modul. Setiap paket memiliki berat sekitar 100 juta dalam bentuk terkompresi. Sekarang kita memiliki jumlah paket satu lebih banyak dari jumlah modul, dengan satu paket dengan berat sekitar 100 juta yang sama, dan sisanya sekitar 500 ribu. Ditambah antarmuka yang lebih ramah pengguna, log yang mudah digunakan, dan yang paling penting - mengurangi waktu untuk memelihara sistem build dan menambahkan konfigurasi. Sekarang menambahkan modul baru membutuhkan waktu 15 menit hingga setengah jam.

Secara terpisah, harus dikatakan tentang template, karena itu adalah standarisasi yang memungkinkan kita menghemat waktu untuk membuat konfigurasi baru dan pemeliharaan lebih lanjut. Semua konfigurasi untuk berinteraksi dengan gurita (penyebaran) dibangun berdasarkan satu templat. Pertama, memungkinkan untuk menyatukan, dan karenanya menyederhanakan proses. Kedua, seperti yang telah disebutkan, menghemat waktu untuk menambahkan konfigurasi baru: kami telah menyambungkan templat, mengubah satu variabel, dan hanya itu. Dan yang paling penting, template menyederhanakan perawatan. Semua perubahan yang dibuat pada templat diwarisi oleh konfigurasi berdasarkan itu. Jadi, jika kita perlu menambahkan beberapa langkah ke semua konfigurasi sekaligus, kita tidak perlu mengklik semuanya, cukup tambahkan langkah ini ke templat.

Tentu saja, proses pengaturan teamcity berjalan seiring dengan pengaturan gurita. Sangat tidak mungkin untuk dijelaskan secara paralel dalam teks, karena ada kemungkinan besar kebingungan. Oleh karena itu, uraian telah dibagikan, dan pada bagian ini hanya langkah-langkah untuk menyediakan CI yang dijelaskan. Proses pengaturan gurita akan dijelaskan sebagai berikut.

Pembaruan Proses CI / CD: teamcity