Kontrol Sumber (Membangun Real-World Cloud Apps dengan Azure)

oleh Rick Anderson, Tom Dykstra

Unduh Fix It Project atau Unduh E-book

E-book Building Real World Cloud Apps dengan Azure didasarkan pada presentasi yang dikembangkan oleh Scott Guthrie. Ini menjelaskan 13 pola dan praktik yang dapat membantu Anda berhasil mengembangkan aplikasi web untuk cloud. Untuk informasi tentang e-book, lihat bab pertama.

Kontrol sumber sangat penting untuk semua proyek pengembangan cloud, bukan hanya lingkungan tim. Anda tidak akan berpikir untuk mengedit kode sumber atau bahkan dokumen Word tanpa fungsi urungkan dan pencadangan otomatis, dan kontrol sumber memberi Anda fungsi tersebut pada tingkat proyek di mana mereka dapat menghemat lebih banyak waktu ketika ada yang salah. Dengan layanan kontrol sumber cloud, Anda tidak perlu lagi khawatir tentang penyiapan yang rumit, dan Anda dapat menggunakan kontrol sumber Azure Repos secara gratis untuk hingga 5 pengguna.

Bagian pertama dari bab ini menjelaskan tiga praktik terbaik utama yang perlu diingat:

• Perlakukan skrip otomatisasi sebagai kode sumber dan buat versinya bersama dengan kode aplikasi Anda.
• Jangan pernah cek masuk rahasia (data sensitif seperti kredensial) ke dalam repositori kode sumber.
• Siapkan cabang sumber untuk mengaktifkan alur kerja DevOps.

Sisa bab memberikan beberapa contoh implementasi pola ini di Visual Studio, Azure, dan Azure Repos:

• Menambahkan skrip ke kontrol sumber di Visual Studio
• Menyimpan data sensitif di Azure
• Menggunakan Git di Visual Studio dan Azure Repos

Perlakukan skrip otomatisasi sebagai kode sumber

Saat mengerjakan proyek cloud, Anda sering mengubah berbagai hal dan ingin dapat bereaksi cepat terhadap masalah yang dilaporkan oleh pelanggan Anda. Merespons dengan cepat melibatkan penggunaan skrip otomatisasi, seperti yang dijelaskan dalam bab Otomatisasi Semuanya . Semua skrip yang Anda gunakan untuk membuat lingkungan Anda, menyebarkannya, menskalakannya, dll., harus sinkron dengan kode sumber aplikasi Anda.

Agar skrip tetap sinkron dengan kode, simpan di sistem kontrol sumber Anda. Kemudian jika Anda perlu mengembalikan perubahan atau melakukan perbaikan cepat pada kode produksi yang berbeda dari kode pengembangan, Anda tidak perlu membuang waktu untuk mencoba melacak pengaturan mana yang telah berubah atau anggota tim mana yang memiliki salinan versi yang Anda butuhkan. Anda yakin bahwa skrip yang Anda butuhkan sinkron dengan basis kode yang Anda butuhkan, dan Anda yakin bahwa semua anggota tim bekerja dengan skrip yang sama. Kemudian apakah Anda perlu mengotomatiskan pengujian dan penyebaran perbaikan panas untuk produksi atau pengembangan fitur baru, Anda akan memiliki skrip yang tepat untuk kode yang perlu diperbarui.

Jangan cek masuk rahasia

Repositori kode sumber biasanya dapat diakses oleh terlalu banyak orang agar menjadi tempat yang aman untuk data sensitif seperti kata sandi. Jika skrip mengandalkan rahasia seperti kata sandi, parameterisasi pengaturan tersebut sehingga tidak disimpan dalam kode sumber, dan simpan rahasia Anda di tempat lain.

Misalnya, Azure memungkinkan Anda mengunduh file yang berisi pengaturan penerbitan untuk mengotomatiskan pembuatan profil penerbitan. File-file ini mencakup nama pengguna dan kata sandi yang berwenang untuk mengelola layanan Azure Anda. Jika Anda menggunakan metode ini untuk membuat profil penerbitan, dan jika Anda memeriksa file-file ini ke kontrol sumber, siapa pun yang memiliki akses ke repositori Anda dapat melihat nama pengguna dan kata sandi tersebut. Anda dapat menyimpan kata sandi dengan aman di profil penerbitan itu sendiri karena dienkripsi dan berada dalam file .pubxml.user yang secara default tidak disertakan dalam kontrol sumber.

Struktur cabang sumber untuk memfasilitasi alur kerja DevOps

Bagaimana Anda menerapkan cabang di repositori Anda memengaruhi kemampuan Anda untuk mengembangkan fitur baru dan memperbaiki masalah dalam produksi. Berikut adalah pola yang digunakan banyak tim berukuran sedang:

Cabang utama selalu cocok dengan kode yang sedang dalam produksi. Cabang di bawah utama sesuai dengan tahap yang berbeda dalam siklus hidup pengembangan. Cabang pengembangan adalah tempat Anda menerapkan fitur baru. Untuk tim kecil Anda mungkin hanya memiliki utama dan pengembangan, tetapi kami sering merekomendasikan agar orang-orang memiliki cabang penahapan antara pengembangan dan utama. Anda dapat menggunakan penahapan untuk pengujian integrasi akhir sebelum pembaruan dipindahkan ke produksi.

Untuk tim besar mungkin ada cabang terpisah untuk setiap fitur baru; untuk tim yang lebih kecil, Anda mungkin meminta semua orang untuk check-in ke cabang pengembangan.

Jika Anda memiliki cabang untuk setiap fitur, ketika Fitur A siap, Anda menggabungkan kode sumbernya berubah menjadi cabang pengembangan dan turun ke cabang fitur lainnya. Proses penggabungan kode sumber ini dapat memakan waktu, dan untuk menghindari pekerjaan tersebut sambil tetap memisahkan fitur, beberapa tim menerapkan tombol fitur alternatif yang disebut (juga dikenal sebagai bendera fitur). Ini berarti semua kode untuk semua fitur berada di cabang yang sama, tetapi Anda mengaktifkan atau menonaktifkan setiap fitur dengan menggunakan sakelar dalam kode. Misalnya, Fitur A adalah bidang baru untuk tugas aplikasi Fix It, dan Fitur B menambahkan fungsionalitas penembolokan. Kode untuk kedua fitur dapat berada di cabang pengembangan, tetapi aplikasi hanya akan menampilkan bidang baru ketika variabel diatur ke true, dan hanya akan menggunakan penembolokan ketika variabel yang berbeda diatur ke true. Jika Fitur A belum siap untuk dipromosikan tetapi Fitur B siap, Anda dapat mempromosikan semua kode ke Produksi dengan sakelar Fitur A nonaktif dan fitur B diaktifkan. Anda kemudian dapat menyelesaikan Fitur A dan mempromosikannya nanti, semua tanpa penggabungan kode sumber.

Baik Anda menggunakan cabang atau beralih untuk fitur atau tidak, struktur percabangan seperti ini memungkinkan Anda mengalirkan kode anda dari pengembangan ke produksi dengan cara yang tangkas dan dapat diulang.

Struktur ini juga memungkinkan Anda untuk bereaksi dengan cepat terhadap umpan balik pelanggan. Jika Anda perlu melakukan perbaikan cepat untuk produksi, Anda juga dapat melakukannya secara efisien dengan cara yang tangkas. Anda dapat membuat cabang dari utama atau penahapan, dan ketika siap menggabungkannya menjadi utama dan turun menjadi cabang pengembangan dan fitur.

Tanpa struktur percabangan seperti ini dengan pemisahan cabang produksi dan pengembangannya, masalah produksi dapat menempatkan Anda pada posisi harus mempromosikan kode fitur baru bersama dengan perbaikan produksi Anda. Kode fitur baru mungkin tidak sepenuhnya diuji dan siap untuk produksi dan Anda mungkin harus melakukan banyak pekerjaan yang mendukung perubahan yang belum siap. Atau Anda mungkin harus menunda perbaikan untuk menguji perubahan dan menyiapkannya untuk disebarkan.

Selanjutnya Anda akan melihat contoh cara menerapkan ketiga pola ini di Visual Studio, Azure, dan Azure Repos. Ini adalah contoh daripada instruksi panduan langkah demi langkah yang terperinci; untuk instruksi terperinci yang menyediakan semua konteks yang diperlukan, lihat bagian Sumber Daya di akhir bab.

Menambahkan skrip ke kontrol sumber di Visual Studio

Anda dapat menambahkan skrip ke kontrol sumber di Visual Studio dengan menyertakannya di folder solusi Visual Studio (dengan asumsi proyek Anda berada dalam kontrol sumber). Berikut adalah salah satu cara untuk melakukannya.

Buat folder untuk skrip di folder solusi Anda (folder yang sama dengan file .sln Anda).

Salin file skrip ke dalam folder.

Di Visual Studio, tambahkan folder solusi ke proyek.

Dan tambahkan file skrip ke folder solusi.

File skrip sekarang disertakan dalam proyek Anda dan kontrol sumber melacak perubahan versinya bersama dengan perubahan kode sumber yang sesuai.

Menyimpan data sensitif di Azure

Jika Anda menjalankan aplikasi Anda di Situs Web Azure, salah satu cara untuk menghindari penyimpanan kredensial dalam kontrol sumber adalah dengan menyimpannya di Azure sebagai gantinya.

Misalnya, aplikasi Fix It menyimpan dalam Web.config filenya dua string koneksi yang akan memiliki kata sandi dalam produksi dan kunci yang memberikan akses ke akun penyimpanan Azure Anda.

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

Jika Anda menempatkan nilai produksi aktual untuk pengaturan ini dalam file Web.config Anda, atau jika Anda memasukkannya ke dalam file Web.Release.config untuk mengonfigurasi transformasi Web.config untuk menyisipkannya selama penyebaran, nilai tersebut akan disimpan di repositori sumber. Jika Anda memasukkan string koneksi database ke profil penerbitan produksi, kata sandi akan berada di file .pubxml Anda. (Anda dapat mengecualikan file .pubxml dari kontrol sumber, tetapi kemudian Anda kehilangan manfaat berbagi semua pengaturan penyebaran lainnya.)

Azure memberi Anda alternatif untuk bagian appSettings dan string koneksi dari file Web.config . Berikut adalah bagian yang relevan dari tab Konfigurasi untuk situs web di portal manajemen Azure:

Saat Anda menyebarkan proyek ke situs web ini dan aplikasi berjalan, nilai apa pun yang telah Anda simpan di Azure mengambil alih nilai apa pun yang ada dalam file Web.config.

Anda dapat mengatur nilai-nilai ini di Azure dengan menggunakan portal manajemen atau skrip. Skrip otomatisasi pembuatan lingkungan yang Anda lihat di bab Otomatisasi Semuanya membuat Database Azure SQL, mendapatkan penyimpanan dan SQL Database string koneksi, dan menyimpan rahasia ini di pengaturan untuk situs web Anda.

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}

# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

Perhatikan bahwa skrip diparameterkan sehingga nilai aktual tidak bertahan ke repositori sumber.

Saat Anda menjalankan secara lokal di lingkungan pengembangan, aplikasi membaca file Web.config lokal dan string koneksi Anda menunjuk ke database SQL Server LocalDB di folder App_Data proyek web Anda. Saat Anda menjalankan aplikasi di Azure dan aplikasi mencoba membaca nilai-nilai ini dari file Web.config, apa yang akan kembali dan digunakan adalah nilai yang disimpan untuk Situs Web, bukan apa yang sebenarnya ada di file Web.config.

Menggunakan Git di Visual Studio dan Azure DevOps

Anda dapat menggunakan lingkungan kontrol sumber apa pun untuk mengimplementasikan struktur percabangan DevOps yang disajikan sebelumnya. Untuk tim terdistribusi, sistem kontrol versi terdistribusi (DVCS) mungkin berfungsi paling baik; untuk tim lain , sistem terpusat mungkin bekerja lebih baik.

Git adalah sistem kontrol versi terdistribusi yang populer. Saat Anda menggunakan Git untuk kontrol sumber, Anda memiliki salinan lengkap repositori dengan semua riwayatnya di komputer lokal Anda. Banyak orang lebih suka karena lebih mudah untuk terus bekerja ketika Anda tidak terhubung ke jaringan - Anda dapat terus melakukan penerapan dan putar kembali, membuat dan beralih cabang, dan sebagainya. Bahkan ketika Anda terhubung ke jaringan, lebih mudah dan lebih cepat untuk membuat cabang dan beralih cabang ketika semuanya lokal. Anda juga dapat melakukan penerapan dan pembatalan lokal tanpa berdampak pada pengembang lain. Dan Anda dapat membuat batch penerapan sebelum mengirimkannya ke server.

Azure Repos menawarkan Kontrol Versi Git dan Team Foundation (TFVC; kontrol sumber terpusat). Mulai menggunakan Azure DevOps di sini.

Visual Studio 2017 menyertakan dukungan Git bawaan kelas satu. Berikut adalah demo cepat tentang cara kerjanya.

Dengan proyek terbuka di Visual Studio, klik kanan solusi di Penjelajah Solusi, lalu pilih Tambahkan Solusi ke Kontrol Sumber.

Visual Studio menanyakan apakah Anda ingin menggunakan TFVC (kontrol versi terpusat) atau Git.

Saat Anda memilih Git dan mengklik OK, Visual Studio membuat repositori Git lokal baru di folder solusi Anda. Repositori baru belum memiliki file; Anda harus menambahkannya ke repositori dengan melakukan penerapan Git. Klik kanan solusi di Penjelajah Solusi, lalu klik Terapkan.

Visual Studio secara otomatis menahapkan semua file proyek untuk penerapan dan mencantumkannya di Team Explorer di panel Perubahan yang Disertakan . (Jika ada beberapa yang tidak ingin Anda sertakan dalam penerapan, Anda dapat memilihnya, klik kanan, dan klik Kecualikan.)

Masukkan komentar penerapan dan klik Terapkan, dan Visual Studio menjalankan penerapan dan menampilkan ID penerapan.

Sekarang jika Anda mengubah beberapa kode sehingga berbeda dari apa yang ada di repositori, Anda dapat dengan mudah melihat perbedaannya. Klik kanan file yang telah Anda ubah, pilih Bandingkan dengan Tidak Dimodifikasi, dan Anda mendapatkan tampilan perbandingan yang memperlihatkan perubahan yang tidak dilakukan.

Anda dapat dengan mudah melihat perubahan apa yang Anda buat dan memeriksanya.

Misalkan Anda perlu membuat cabang - Anda juga dapat melakukannya di Visual Studio. Di Team Explorer, klik Cabang Baru.

Masukkan nama cabang, klik Buat Cabang, dan jika Anda memilih cabang Checkout, Visual Studio secara otomatis memeriksa cabang baru.

Anda sekarang dapat membuat perubahan pada file dan memeriksanya ke cabang ini. Dan Anda dapat dengan mudah beralih antara cabang dan Visual Studio secara otomatis menyinkronkan file ke cabang mana pun yang telah Anda periksa. Dalam contoh ini judul halaman web di _Layout.cshtml telah diubah menjadi "Perbaikan Panas 1" di cabang HotFix1.

Jika Anda beralih kembali ke cabang utama , konten file _Layout.cshtml secara otomatis kembali ke apa yang ada di cabang utama .

Ini adalah contoh sederhana tentang bagaimana Anda dapat dengan cepat membuat cabang dan membalik bolak-balik antar cabang. Fitur ini memungkinkan alur kerja yang sangat tangkas menggunakan struktur cabang dan skrip otomatisasi yang disajikan dalam bab Otomatisasi Semuanya . Misalnya, Anda dapat bekerja di cabang Pengembangan, membuat cabang perbaikan panas dari utama, beralih ke cabang baru, membuat perubahan Anda di sana dan menerapkannya, lalu beralih kembali ke cabang Pengembangan dan melanjutkan apa yang Anda lakukan.

Apa yang telah Anda lihat di sini adalah cara Anda bekerja dengan repositori Git lokal di Visual Studio. Di lingkungan tim, Anda biasanya juga mendorong perubahan ke repositori umum. Alat Visual Studio juga memungkinkan Anda menunjuk ke repositori Git jarak jauh. Anda dapat menggunakan GitHub.com untuk tujuan tersebut, atau Anda dapat menggunakan Git dan Azure Repos yang terintegrasi dengan semua kemampuan Azure DevOps lainnya seperti item kerja dan pelacakan bug.

Ini bukan satu-satunya cara Anda dapat menerapkan strategi percabangan yang tangkas, tentu saja. Anda dapat mengaktifkan alur kerja agile yang sama menggunakan repositori kontrol sumber terpusat.

Ringkasan

Ukur keberhasilan sistem kontrol sumber Anda berdasarkan seberapa cepat Anda dapat membuat perubahan dan membuatnya hidup dengan cara yang aman dan dapat diprediksi. Jika Anda merasa takut untuk membuat perubahan karena Anda harus melakukan satu atau dua hari pengujian manual di atasnya, Anda mungkin bertanya pada diri sendiri apa yang harus Anda lakukan proses-bijaksana atau uji-bijaksana sehingga Anda dapat membuat perubahan itu dalam hitungan menit atau terburuk tidak lebih dari satu jam. Salah satu strategi untuk melakukan itu adalah menerapkan integrasi berkelanjutan dan pengiriman berkelanjutan, yang akan kita bab berikutnya.

Sumber

Untuk informasi selengkapnya tentang strategi percabangan, lihat sumber daya berikut ini:

• Membangun Alur Rilis dengan Team Foundation Server 2012. Dokumentasi Pola dan Praktik Microsoft. Lihat bab 6 untuk diskusi tentang strategi percabangan. Fitur advokat beralih ke cabang fitur, dan jika cabang untuk fitur digunakan, advokat menjaganya tetap berumur pendek (paling banyak jam atau hari).
• Panduan Kontrol Versi. Panduan untuk strategi percabangan oleh ALM Rangers. Lihat Strategies.pdf Pencabangan pada tab Unduhan.
• Pengembangan Perangkat Lunak dengan Tombol Fitur. Artikel Majalah MSDN.
• Tombol Fitur. Pengantar pengalih fitur / bendera fitur di blog Martin Fowler.
• Pengalih Fitur vs Cabang Fitur. Posting blog lain tentang pengalih fitur, oleh Dylan Smith.

Untuk informasi selengkapnya tentang cara menangani informasi sensitif yang tidak boleh disimpan di repositori kontrol sumber, lihat sumber daya berikut ini:

• Praktik terbaik untuk menyebarkan kata sandi dan data sensitif lainnya ke ASP.NET dan Azure App Service.
• Situs Web Azure: Cara Kerja String Aplikasi dan String Koneksi. Menjelaskan fitur Azure yang mengambil appSettings alih dan connectionStrings data dalam file Web.config .
• Konfigurasi kustom dan pengaturan aplikasi di Situs Web Azure - dengan Stefan Schackow.

Untuk informasi tentang metode lain untuk menjaga informasi sensitif di luar kontrol sumber, lihat ASP.NET MVC: Menjaga Pengaturan Privat Tetap Berada di Luar Kontrol Sumber.

SebelumnyaBerikutnya