Integrasi Berkelanjutan - Panduan Cepat
Integrasi Berkelanjutan pertama kali diperkenalkan pada tahun 2000 dengan perangkat lunak yang dikenal sebagai Cruise Control. Selama bertahun-tahun, Integrasi Berkelanjutan telah menjadi praktik utama dalam organisasi perangkat lunak mana pun. Ini adalah praktik pengembangan yang meminta tim pengembangan untuk memastikan bahwa build dan pengujian selanjutnya dilakukan untuk setiap perubahan kode yang dibuat ke program perangkat lunak. Konsep ini dimaksudkan untuk menghilangkan masalah menemukan kemunculan masalah yang terlambat dalam siklus proses build. Alih-alih pengembang bekerja dalam isolasi dan tidak cukup terintegrasi, Integrasi Berkelanjutan diperkenalkan untuk memastikan bahwa perubahan kode dan pembuatan tidak pernah dilakukan secara terpisah.
Mengapa Integrasi Berkelanjutan?
Integrasi berkelanjutan telah menjadi bagian yang sangat integral dari proses pengembangan perangkat lunak apa pun. Proses Integrasi berkelanjutan membantu menjawab pertanyaan-pertanyaan berikut untuk tim pengembangan perangkat lunak.
Apakah semua komponen perangkat lunak bekerja bersama sebagaimana mestinya? - Terkadang sistem bisa menjadi sangat kompleks sehingga ada banyak antarmuka untuk setiap komponen. Dalam kasus seperti itu, selalu penting untuk memastikan bahwa semua komponen perangkat lunak bekerja dengan lancar satu sama lain.
Apakah kode terlalu rumit untuk tujuan integrasi? - Jika proses integrasi berkelanjutan terus gagal, ada kemungkinan kode tersebut terlalu rumit. Dan ini bisa menjadi sinyal untuk menerapkan pola desain yang tepat untuk membuat kode lebih kompleks dan lebih mudah dipelihara.
Apakah kode tersebut mematuhi standar pengkodean yang ditetapkan? - Sebagian besar kasus pengujian akan selalu memeriksa bahwa kode tersebut mematuhi standar pengkodean yang tepat. Dengan melakukan tes otomatis setelah pembuatan otomatis, ini adalah poin yang baik untuk memeriksa apakah kode tersebut memenuhi semua standar pengkodean yang diinginkan.
Berapa banyak kode yang dicakup oleh pengujian otomatis? - Tidak ada gunanya menguji kode jika kasus pengujian tidak mencakup fungsionalitas kode yang diperlukan. Jadi, selalu merupakan praktik yang baik untuk memastikan bahwa kasus uji tertulis harus mencakup semua skenario utama aplikasi.
Apakah semua pengujian berhasil setelah perubahan terbaru? - Jika tes gagal, maka tidak ada gunanya melanjutkan penerapan kode, jadi ini adalah poin yang baik untuk memeriksa apakah kode siap untuk dipindahkan ke tahap penerapan atau tidak.
Alur Kerja
Gambar berikut menunjukkan alur kerja cepat tentang cara kerja seluruh alur kerja Continuous Integration dalam proyek pengembangan perangkat lunak apa pun. Kami akan melihat ini secara rinci di bab-bab selanjutnya.
Jadi, berdasarkan alur kerja di atas, ini biasanya cara kerja proses integrasi berkelanjutan.
Pertama, pengembang memasukkan kode ke repositori kontrol versi. Sementara itu, server Integrasi Berkelanjutan pada mesin build integrasi memeriksa repositori kode sumber untuk perubahan (misalnya, setiap beberapa menit).
Segera setelah komit terjadi, server Integrasi Berkelanjutan mendeteksi bahwa perubahan telah terjadi di repositori kontrol versi, sehingga server Integrasi Berkelanjutan mengambil salinan kode terbaru dari repositori dan kemudian menjalankan skrip build, yang mengintegrasikan perangkat lunak
Server Integrasi Berkelanjutan menghasilkan umpan balik dengan mengirimkan hasil build melalui email ke anggota proyek yang ditentukan.
Tes unit kemudian dilakukan jika pembangunan proyek itu berhasil. Jika pengujian berhasil, kode siap untuk diterapkan ke server penahapan atau produksi.
Server Integrasi Berkelanjutan terus mengumpulkan perubahan dalam repositori kontrol versi dan seluruh proses berulang.
Bagian perangkat lunak adalah aspek terpenting dari setiap proses Integrasi Berkelanjutan. Bab ini berfokus pada perangkat lunak yang akan dibutuhkan untuk seluruh proses Integrasi Berkelanjutan.
Repositori Kode Sumber
Repositori kode sumber digunakan untuk memelihara semua kode sumber dan semua perubahan yang dibuat padanya. Dua yang paling populer untuk manajemen repositori kode sumber adalah subversi dan Git dengan Git menjadi sistem populer terbaru. Sekarang kita akan melihat bagaimana menginstal Git pada sistem.
Persyaratan sistem
| Penyimpanan | RAM 2 GB (disarankan) |
| Ruang Disk | 200 MB HDD untuk instalasi. Penyimpanan tambahan diperlukan untuk menyimpan kode sumber proyek dan ini bergantung pada kode sumber yang ditambahkan. |
| Versi Sistem Operasi | Dapat diinstal di Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X. |
Menginstal Git
Step 1 - Situs web resmi untuk Git adalah https://git-scm.com/. Jika Anda mengklik tautannya, Anda akan masuk ke halaman beranda situs web resmi Git seperti yang ditunjukkan pada tangkapan layar berikut.
Step 2 - Untuk mengunduh Git, cukup gulir ke bawah layar dan buka bagian Unduhan dan klik Unduhan.
Step 3 - Klik tautan Windows dan unduhan untuk Git akan dimulai secara otomatis.
Step 4- Klik file .exe yang diunduh untuk Git. Dalam kasus kami, kami menggunakan file Git-2.6.1-64-bit.exe. Klik Jalankan yang muncul di layar berikutnya.
Step 5 - Klik tombol Berikutnya yang muncul di layar berikut.
Step 6 - Klik Berikutnya di layar berikut untuk menerima perjanjian Lisensi Umum.
Step 7 - Pilih lokasi untuk instalasi Git Anda.
Step 8 - Klik Next untuk menerima komponen default yang perlu diinstal.
Step 9 - Pilih opsi 'Gunakan Git dari prompt perintah Windows' karena kita akan menggunakan Git dari Windows.
Step 10 - Pada layar berikut, terima pengaturan default 'Checkout Windows-style, lakukan ujung baris Unix-style' dan klik Next.
Step 11 - Pada layar berikut, pilih opsi 'Gunakan jendela konsol default Windows', karena kami menggunakan Windows sebagai sistem untuk instalasi Git.
Instalasi sekarang akan dimulai, dan langkah-langkah selanjutnya dapat diikuti untuk mengkonfigurasi Git, setelah instalasi selesai.
Mengonfigurasi Git
Setelah Git terinstal, langkah-langkah konfigurasi perlu dilakukan untuk konfigurasi awal Git.
Hal pertama yang perlu dilakukan adalah mengkonfigurasi identitas di Git dan kemudian mengkonfigurasi nama pengguna dan email. Ini penting karena setiapGit commitmenggunakan informasi ini, dan itu selalu dimasukkan ke dalam commit yang Anda mulai buat. Seseorang dapat melakukan ini dengan membuka command prompt dan kemudian memasukkan perintah berikut -
git config –global user.name “Username”
git config –global user.email “emailid”Tangkapan layar berikut adalah contoh untuk pemahaman yang lebih baik.
Perintah-perintah ini sebenarnya akan mengubah file konfigurasi Git. Untuk memastikan pengaturan Anda diterapkan, Anda dapat mendaftar pengaturan file konfigurasi Git dengan menggunakan perintah berikut.
git config --listContoh keluarannya ditunjukkan pada tangkapan layar berikut.
Server Integrasi Berkelanjutan
Perangkat lunak penting berikutnya yang diperlukan untuk seluruh pipeline integrasi berkelanjutan adalah perangkat lunak Continuous Integration itu sendiri. Berikut ini adalah software Continuous Integration yang paling umum digunakan yang digunakan di industri -
Jenkins- Ini adalah perangkat lunak Integrasi Berkelanjutan sumber terbuka yang digunakan oleh banyak komunitas pengembang.
Jet Brains TeamCity - Ini adalah salah satu perangkat lunak Integrasi Berkelanjutan komersial paling populer yang tersedia dan sebagian besar perusahaan menggunakan ini untuk kebutuhan Integrasi Berkelanjutan mereka.
Atlassian Bamboo- Ini adalah software Continuous Integration populer lainnya yang disediakan oleh perusahaan bernama Atlassian Pvt. Ltd.
Semua perangkat lunak yang disebutkan di atas, bekerja pada model yang sama untuk Integrasi Berkelanjutan. Untuk tujuan tutorial ini, kita akan melihatJetbrains TeamCity untuk server Integrasi Berkelanjutan.
Menginstal TeamCity
Berikut adalah langkah-langkah dan persyaratan sistem untuk menginstal Jet Brains TeamCity di komputer Anda.
Persyaratan sistem
| Penyimpanan | RAM 4 GB (disarankan) |
| Ruang Disk | HDD 1 GB untuk instalasi. Penyimpanan tambahan diperlukan untuk menyimpan ruang kerja build untuk setiap proyek. |
| Versi Sistem Operasi | Dapat diinstal di Windows, Linux, Mac OS X. |
Instalasi
Step 1 - Situs web resmi untuk TeamCity adalahhttps://www.jetbrains.com/teamcity/. Jika Anda mengklik tautan yang diberikan, Anda akan masuk ke halaman beranda situs web resmi TeamCity seperti yang ditunjukkan pada tangkapan layar berikut. Anda dapat menelusuri halaman untuk mengunduh perangkat lunak yang diperlukan untuk TeamCity.
Step 2 - .exe yang diunduh digunakan untuk tujuan eksekusi TeamCity-9.1.6.exe. Klik dua kali file yang dapat dieksekusi lalu klik Jalankan di layar berikutnya yang muncul.
Step 3 - Klik Berikutnya untuk memulai penyiapan.
Step 4 - Klik tombol 'Saya Setuju' untuk menerima perjanjian lisensi dan melanjutkan penginstalan.
Step 5 - Pilih lokasi penginstalan dan klik Berikutnya.
Step 6 - Pilih komponen default untuk instalasi dan klik Next
Ini akan memulai proses instalasi. Setelah selesai proses konfigurasi akan mengikuti.
Step 7- Pilih nomor port untuk menjalankan server. Yang terbaik adalah menggunakan port yang berbeda seperti8080.
Step 8- Selanjutnya akan ditanyakan akun mana yang harus dijalankan TeamCity. Pilih akun SISTEM dan Klik Berikutnya.
Step 9- Selanjutnya akan ditanyakan layanan yang perlu dimulai. Terima yang default dan kemudian klik Next.
Mengonfigurasi TeamCity
Setelah penginstalan selesai, langkah selanjutnya adalah konfigurasi TeamCity. Perangkat lunak ini dapat dibuka dengan menelusuri URL berikut di browser -
http://locahost:8080
Step 1- Langkah pertama adalah menyediakan lokasi build yang akan dilakukan oleh TeamCity. Pilih lokasi yang diinginkan dan klik tombol Lanjutkan.
Step 2- Langkah selanjutnya adalah menentukan database untuk menyimpan semua artefak TeamCity. Untuk tujuan tutorial, seseorang dapat memilih fileInternal (HSQLDB), yang merupakan database internal yang paling sesuai saat menggunakan produk untuk tujuan pengujian.
TeamCity kemudian akan memproses semua langkah yang diperlukan untuk mengaktifkan dan menjalankannya.
Step 3- Selanjutnya Anda akan diminta untuk Menerima perjanjian lisensi. Terima hal yang sama dan klik Lanjutkan.
Step 4- Anda perlu membuat akun administrator yang akan digunakan untuk masuk ke perangkat lunak TeamCity. Masukkan detail yang diperlukan dan klik tombol 'Buat Akun'.
Anda sekarang akan masuk ke TeamCity.
Alat Bangun
Alat Build adalah alat yang memastikan bahwa program dibuat dengan cara tertentu. Alat ini biasanya akan menjalankan daftar tugas, yang diperlukan untuk program yang akan dibangun dengan cara yang tepat. Karena dalam contoh kita, kita akan melihat a.Net program , kami akan melihat MSBuildsebagai alat pembuatan. Alat MSBuild melihat file build yang berisi daftar tugas yang digunakan untuk membangun proyek. Mari kita lihat file Build khas untuk proyek konfigurasi web.
Berikut adalah bagian utama dari file Build, yang perlu dipertimbangkan.
Pengaturan IIS
Pengaturan berikut digunakan untuk menentukan mana yang merupakan nomor port, apa jalur di server web dan jenis otentikasi apa yang diperlukan saat aplikasi dijalankan. Ini adalah pengaturan penting, yang akan diubah melalui perintah MSBuild saat kita mempelajari bagaimana penerapan akan dilakukan nanti di tutorial.
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>ItemGroup
Ini digunakan untuk memberi tahu Build server apa saja biner dependen yang diperlukan untuk menjalankan proyek ini.
<ItemGroup>
<Reference Include = "System.Web.ApplicationServices" />
<Reference Include = "System.ComponentModel.DataAnnotations" /><ItemGroup>
<Compile Include = "App_Start\BundleConfig.cs" />
<Compile Include = "App_Start\FilterConfig.cs" />Versi Net Framework
Itu TargetFrameworkVersionmemberi tahu versi .Net mana yang perlu ada agar proyek dapat berfungsi. Ini mutlak diperlukan karena jika server build tidak memiliki ini, build akan gagal.
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>Lingkungan Penerapan - Amazon
Untuk tujuan tutorial ini, kami akan memastikan server Integrasi Berkelanjutan kami memiliki kemampuan untuk menerapkan aplikasi kami ke Amazon. Untuk ini, kita perlu memastikan artefak berikut ada di tempatnya.
Server Database
Lakukan langkah-langkah berikut untuk memastikan bahwa server database sudah siap di Amazon untuk penerapan.
Step 1 - Buka Konsol Amazon - https://aws.amazon.com/console/.
Masuk dengan kredensial Anda. Perhatikan bahwa Anda dapat mengajukan id gratis di situs amazon, yang memungkinkan Anda memiliki tingkat gratis yang memungkinkan Anda menggunakan beberapa sumber daya di Amazon secara gratis.
Step 2 - Buka Bagian RDS untuk membuat database Anda.
Step 3 - Klik Instance di layar berikutnya yang muncul.
Step 4 - Klik Launch DB opsi di layar berikutnya yang muncul.
Step 5 - Pilih tab SQL Server dan kemudian pilih opsi Pilih untuk SQL Server Express.
Step 6 - Pastikan bahwa detail berikut dimasukkan untuk mengonfirmasi bahwa Anda menggunakan tingkat database gratis yang tersedia dari Amazon.
Step 7 - Klik tombol Langkah Berikutnya setelah semua bidang terisi.
Step 8 - Di layar berikutnya yang muncul, terima semua pengaturan default dan Klik Launch DB Instance.
Step 9- Kemudian Anda akan disajikan dengan layar yang mengatakan bahwa DB berhasil diluncurkan. Di halaman yang sama, akan ada tombol untuk melihat Instans DB. Klik tautan untuk melihatDB Instance sedang disiapkan.
Setelah beberapa waktu, status layar di atas akan berubah untuk memberi tahu bahwa Instans DB telah berhasil dibuat.
Server Web
Langkah selanjutnya adalah membuat server web Anda di Amazon, yang akan menghosting aplikasi web. Ini dapat dilakukan dengan mengikuti langkah-langkah selanjutnya untuk menerapkannya.
Step 1 - Buka Konsol Amazon - https://aws.amazon.com/console/.
Masuk dengan kredensial Anda. Perhatikan bahwa Anda dapat mengajukan permohonan untuk afree id on the Amazon site, yang memungkinkan Anda memiliki tingkat gratis yang memungkinkan Anda menggunakan beberapa sumber daya di Amazon tanpa biaya.
Step 2 - Pergi ke EC2 section untuk membuat server web Anda.
Step 3 - Di layar berikutnya, klik Luncurkan Instance.
Step 4 - Klik Windows - Microsoft Windows Server 2010 R2 Base.
Step 5 - Pilih t2.microopsi, yang merupakan bagian dari tingkat gratis. KlikNext: Configure Instance Details.
Step 6 - Terima pengaturan default di layar berikutnya yang muncul dan kemudian pilih opsi Next: Add Storage.
Step 7 - Terima pengaturan default di layar berikutnya dan pilih opsi Next: Tag Instance.
Step 8 - Terima pengaturan default di layar berikutnya dan pilih opsi Next: Configure Security Group.
Step 9 - Terima pengaturan default di layar berikutnya dan pilih opsi Review and Launch.
Step 10 - Klik Luncurkan di layar berikutnya yang muncul.
Step 11- Di layar berikutnya yang muncul, Anda akan diminta untuk membuat pasangan kunci. Ini akan digunakan untuk masuk ke server di lain waktu. Cukup buat pasangan kunci dan klikLaunch Instance.
Instans sekarang akan disiapkan di Amazon.
Ada kemungkinan terjadi kesalahan pada proyek. Dengan mempraktikkan CI secara efektif, Anda mengetahui apa yang terjadi di setiap langkah di sepanjang jalan, bukan di kemudian hari saat proyek berada dalam siklus pengembangan. CI membantu Anda mengidentifikasi dan memitigasi risiko ketika terjadi, sehingga lebih mudah untuk mengevaluasi dan melaporkan kesehatan proyek berdasarkan bukti nyata.
Bagian ini akan berkonsentrasi pada risiko yang dapat dihindari dengan menggunakan Integrasi Berkelanjutan.
Pada proyek apa pun, ada banyak risiko yang perlu dikelola. Dengan menghilangkan risiko lebih awal dalam siklus hidup pengembangan, ada kemungkinan lebih kecil risiko ini berkembang menjadi masalah di kemudian hari, saat sistem benar-benar berjalan.
Risiko 1 - Kurangnya Perangkat Lunak yang Dapat Disebarkan
“It works on my machine but does not work on another”- Ini mungkin salah satu frasa paling umum yang ditemukan dalam organisasi perangkat lunak mana pun. Karena jumlah perubahan yang dilakukan pada perangkat lunak yang dibangun setiap hari, terkadang ada sedikit kepercayaan tentang apakah pembangunan perangkat lunak benar-benar berfungsi atau tidak. Kekhawatiran ini memiliki tiga efek samping berikut.
Sedikit atau tidak ada kepercayaan apakah kami bahkan dapat membangun perangkat lunak.
Fase integrasi yang panjang sebelum mengirimkan perangkat lunak secara internal (mis., Tim uji) atau secara eksternal (mis., Pelanggan), selama waktu itu tidak ada yang dilakukan.
Ketidakmampuan untuk memproduksi dan mereproduksi build yang dapat diuji.
Larutan
Menghilangkan keterkaitan erat antara IDE dan proses build. Gunakan mesin terpisah hanya untuk mengintegrasikan perangkat lunak. Pastikan bahwa semua yang Anda butuhkan untuk membangun perangkat lunak ada dalam repositori kontrol versi. Terakhir, buat sistem Integrasi Berkelanjutan.
Server Integrasi Berkelanjutan dapat mengamati perubahan dalam repositori kontrol versi dan menjalankan skrip build proyek ketika mendeteksi perubahan pada repositori. Kemampuan sistem Integrasi Berkelanjutan dapat ditingkatkan untuk menyertakan pembuatan yang dijalankan melalui pengujian, melakukan inspeksi, dan menyebarkan perangkat lunak di lingkungan pengembangan dan pengujian; dengan cara ini Anda selalu memiliki perangkat lunak yang berfungsi.
“Inability to synchronize with the database”- Terkadang pengembang tidak dapat membuat ulang basis data dengan cepat selama pengembangan, dan karenanya kesulitan untuk membuat perubahan. Seringkali hal ini disebabkan oleh pemisahan antara tim database dan tim pengembangan. Setiap tim akan fokus pada tanggung jawab mereka sendiri dan memiliki sedikit kolaborasi antara satu sama lain. Kekhawatiran ini memiliki tiga efek samping berikut -
Takut membuat perubahan atau refactoring database atau kode sumber.
Kesulitan dalam mengisi database dengan set data uji yang berbeda.
Kesulitan dalam memelihara lingkungan pengembangan dan pengujian (misalnya, Pengembangan, Integrasi, QA, dan Pengujian).
Larutan
Solusi untuk masalah di atas adalah memastikan bahwa penempatan semua artefak database di repositori kontrol versi dilakukan. Ini berarti semua yang diperlukan untuk membuat ulang skema database dan data: skrip pembuatan database, skrip manipulasi data, prosedur tersimpan, pemicu, dan aset database lainnya diperlukan.
Buat ulang database dan data dari skrip build Anda, dengan melepaskan dan membuat ulang database dan tabel Anda. Selanjutnya, terapkan prosedur dan pemicu yang tersimpan, dan terakhir, masukkan data pengujian.
Uji (dan periksa) database Anda. Biasanya, Anda akan menggunakan pengujian komponen untuk menguji database dan data. Dalam beberapa kasus, Anda perlu menulis pengujian khusus database.
Risiko 2 - Menemukan Cacat di Akhir Siklus Hidup
Karena ada begitu banyak perubahan yang sering terjadi oleh banyak pengembang pada kode sumber, selalu ada kemungkinan bahwa cacat dapat dimasukkan dalam kode yang hanya dapat dideteksi pada tahap selanjutnya. Dalam kasus seperti ini, hal ini dapat menimbulkan dampak yang besar karena semakin lama cacat terdeteksi pada perangkat lunak, semakin mahal biaya untuk menghilangkan cacat tersebut.
Larutan
Regression Testing- Ini adalah aspek terpenting dari setiap siklus pengembangan perangkat lunak, uji dan uji lagi. Jika ada perubahan besar pada kode perangkat lunak, sangatlah wajib untuk memastikan bahwa semua tes dijalankan. Dan ini dapat diotomatiskan dengan bantuan server Continuous Integration.
Test Coverage- Tidak ada gunanya menguji jika kasus uji tidak mencakup seluruh fungsionalitas kode. Penting untuk memastikan bahwa kasus pengujian yang dibuat untuk menguji aplikasi sudah lengkap dan semua jalur kode telah diuji.
Misalnya, jika Anda memiliki layar login yang perlu diuji, Anda tidak dapat memiliki kasus pengujian yang memiliki skenario login yang berhasil. Anda perlu memiliki kasus uji negatif di mana pengguna memasukkan kombinasi nama pengguna dan kata sandi yang berbeda dan kemudian diminta untuk melihat apa yang terjadi dalam skenario tersebut.
Risiko 3 - Kurangnya Visibilitas Proyek
Mekanisme komunikasi manual memerlukan banyak koordinasi untuk memastikan penyebaran informasi proyek kepada orang yang tepat pada waktu yang tepat. Bergantung pada pengembang di sebelah Anda dan memberi tahu mereka bahwa versi terbaru ada di drive bersama cukup efektif, namun tidak berskala dengan baik.
Bagaimana jika ada pengembang lain yang membutuhkan informasi ini dan mereka sedang istirahat atau tidak tersedia? Jika server mati, bagaimana Anda diberi tahu? Beberapa percaya bahwa mereka dapat mengurangi risiko ini dengan mengirim email secara manual. Namun, hal ini tidak dapat memastikan informasi dikomunikasikan kepada orang yang tepat pada waktu yang tepat karena Anda mungkin secara tidak sengaja meninggalkan pihak yang berkepentingan, dan beberapa mungkin tidak memiliki akses ke email mereka pada saat itu.
Larutan
Solusi untuk masalah ini sekali lagi adalah server Integrasi Berkelanjutan. Semua server CI memiliki fasilitas untuk memiliki email otomatis yang akan dipicu setiap kali build gagal. Dengan pemberitahuan otomatis ini kepada semua pemangku kepentingan utama, juga dipastikan bahwa setiap orang mengetahui tentang keadaan perangkat lunak saat ini.
Risiko 4 - Perangkat Lunak Berkualitas Rendah
Ada cacat dan ada kemungkinan cacat. Anda dapat memiliki potensi kerusakan jika perangkat lunak Anda tidak dirancang dengan baik atau jika tidak mengikuti standar proyek, atau rumit untuk dirawat. Kadang-kadang orang menyebutnya sebagai kode atau bau desain - "gejala bahwa ada sesuatu yang salah".
Beberapa percaya bahwa perangkat lunak berkualitas rendah hanya merupakan biaya proyek yang ditangguhkan (setelah pengiriman). Ini bisa menjadi biaya proyek yang ditangguhkan, tetapi juga menyebabkan banyak masalah lain sebelum Anda mengirimkan perangkat lunak kepada pengguna. Kode yang terlalu kompleks, kode yang tidak mengikuti arsitektur, dan kode duplikat - semuanya biasanya menyebabkan kerusakan pada perangkat lunak. Menemukan kode dan bau desain ini sebelum terwujud menjadi cacat dapat menghemat waktu dan uang, dan dapat menghasilkan perangkat lunak berkualitas lebih tinggi.
Larutan
Terdapat komponen perangkat lunak untuk melakukan pemeriksaan kualitas kode yang dapat diintegrasikan dengan perangkat lunak CI. Ini dapat dijalankan setelah kode dibuat untuk memastikan bahwa kode tersebut benar-benar sesuai dengan pedoman pengkodean yang tepat.
Sistem kontrol versi, juga dikenal sebagai kontrol sumber, sistem manajemen kode sumber, atau sistem kontrol revisi, adalah mekanisme untuk menyimpan beberapa versi file Anda, sehingga saat Anda memodifikasi file, Anda masih dapat mengakses revisi sebelumnya.
Sistem kontrol versi populer pertama adalah alat UNIX berpemilik yang disebut SCCS(Source Code Control System) yang berasal dari tahun 1970-an. Ini digantikan olehRCS, Sistem Kontrol Revisi, dan yang lebih baru CVS, Sistem Versi Bersamaan.
Sekarang sistem kontrol versi yang paling populer digunakan adalah Subversion dan Git. Pertama mari kita lihat mengapa kita perlu menggunakan sistem kontrol versi dan selanjutnya mari kita lihat memasukkan kode sumber kitaGit source code repository system.
Tujuan Sistem Kontrol Versi
Salah satu alasan kami menggunakan istilah kontrol versi dalam preferensi untuk kontrol sumber adalah bahwa kontrol versi tidak hanya untuk kode sumber. Setiap artefak yang terkait dengan pembuatan perangkat lunak Anda harus berada di bawah kendali versi.
Developers should use it for source code - Secara default, semua kode sumber harus disimpan di sistem kontrol versi
Related artefacts- Setiap sistem akan memiliki artefak yang terkait dengan kode sumber seperti skrip basis data, skrip pembuatan dan penerapan, dokumentasi, pustaka dan file konfigurasi untuk aplikasi Anda, kompilator dan kumpulan alat, dan seterusnya. Semua ini melengkapi keseluruhan proses pengembangan dan penerapan dan juga perlu disimpan dalam sistem kontrol versi.
Dengan menyimpan semua informasi untuk aplikasi di kontrol sumber, akan lebih mudah untuk membuat ulang lingkungan pengujian dan produksi tempat aplikasi Anda berjalan. Ini harus mencakup informasi konfigurasi untuk tumpukan perangkat lunak aplikasi Anda dan sistem operasi yang mencakup lingkungan, File Zona DNS, Konfigurasi Firewall, dan seterusnya.
Minimal, Anda memerlukan semua yang diperlukan untuk membuat ulang binari aplikasi Anda dan lingkungan tempat mereka berjalan. Tujuannya adalah agar segala sesuatu yang mungkin dapat berubah pada titik mana pun dalam kehidupan proyek disimpan dengan cara yang terkendali. Hal ini memungkinkan Anda untuk memulihkan snapshot yang tepat dari keadaan keseluruhan sistem, dari lingkungan pengembangan hingga lingkungan produksi, pada titik mana pun dalam riwayat proyek.
Hal ini bahkan membantu untuk menyimpan file konfigurasi untuk lingkungan pengembangan tim pengembangan dalam kontrol versi karena memudahkan setiap orang di tim untuk menggunakan pengaturan yang sama. Analis harus menyimpan dokumen persyaratan. Penguji harus menyimpan skrip dan prosedur pengujian dalam kontrol versi. Manajer proyek harus menyimpan rencana rilis, grafik kemajuan, dan catatan risiko mereka di sini.
Singkatnya, setiap anggota tim harus menyimpan dokumen atau file yang terkait dengan proyek dalam kontrol versi.
Bekerja dengan Git untuk Sistem Kontrol Versi Kode Sumber
Bagian ini sekarang akan fokus pada bagaimana Git dapat digunakan sebagai sistem kontrol versi. Ini akan berfokus pada bagaimana Anda dapat mengunggah kode Anda ke sistem kontrol versi dan mengelola perubahan di dalamnya.
Aplikasi Demo kami
Untuk tujuan seluruh tutorial ini, kita akan melihat yang sederhana Web ASP.Netaplikasi yang akan digunakan untuk seluruh Proses Integrasi Berkelanjutan. Kami tidak perlu fokus pada keseluruhan detail kode untuk latihan ini, hanya memiliki gambaran umum tentang apa yang dilakukan proyek sudah cukup untuk memahami keseluruhan proses integrasi berkelanjutan. Aplikasi .Net ini dibangun menggunakanVisual Studio Integrated Development Environment.
Tangkapan layar berikut ini adalah struktur solusi di lingkungan Visual Studio. Ini adalah aplikasi Web yang sangat sederhana yang memiliki kode utama diDemo.aspx mengajukan.
Kode di file Demo.aspx ditampilkan di program berikut -
<html xmlns = "http://www.w3.org/1999/xhtml">
<head runat = "server">
<title>TutorialsPoint</title>
</head>
<body>
<form id = "form1" runat="server">
<div><%Response.Write("Continuous Integration"); %></div>
</form>
</body>
</html>Kode ini sangat sederhana dan hanya mengeluarkan string “Continuous Integration” ke browser.
Saat Anda menjalankan proyek di Google Chrome, hasilnya akan seperti yang ditunjukkan pada tangkapan layar berikut.
Memindahkan Kode Sumber ke Git
Kami akan menunjukkan cara memindahkan kode sumber ke Git dari antarmuka baris perintah, sehingga pengetahuan tentang bagaimana Git dapat digunakan lebih jelas bagi pengguna akhir.
Step 1 - Inisialisasi Git Repository. Buka prompt perintah, masuk ke folder proyek Anda dan keluarkan perintahgit init. Perintah ini akan menambahkan file Git yang diperlukan ke folder proyek, sehingga dapat dikenali oleh Git ketika perlu diunggah ke repositori.
Step 2- Menambahkan file Anda yang perlu ditambahkan ke repositori Git. Ini dapat dilakukan dengan menerbitkangit add command. Opsi titik memberi tahu Git bahwa semua file dalam folder proyek perlu ditambahkan ke repositori Git.
Step 3- Langkah terakhir adalah memasukkan file proyek ke repositori Git. Langkah ini diperlukan untuk memastikan semua file sekarang menjadi bagian dari Git. Perintah yang akan dikeluarkan diberikan pada tangkapan layar berikut. Itu–m option adalah memberikan komentar untuk upload file.
Solusi Anda sekarang tersedia di Git.
Berikut adalah beberapa fitur atau praktik utama untuk Integrasi Berkelanjutan.
Maintain a single source repository- Semua kode sumber disimpan dalam satu repositori. Ini untuk menghindari kode sumber tersebar di beberapa lokasi. Alat sepertiSubversion and Git adalah alat paling populer untuk memelihara kode sumber.
Automate the build- Pembuatan perangkat lunak harus dilakukan sedemikian rupa sehingga dapat diotomatisasi. Jika ada beberapa langkah yang perlu dilakukan, maka alat build harus mampu melakukan ini. Untuk .Net, MSBuild adalah alat pembuatan default dan untuk aplikasi berbasis Java Anda memiliki alat sepertiMaven and Grunt.
Make your build self-testing- Bangunan harus dapat diuji. Segera setelah build terjadi, kasus uji harus dijalankan untuk memastikan bahwa pengujian dapat dilakukan untuk berbagai fungsionalitas perangkat lunak.
Every commit should build on an integration machine- Mesin integrasi adalah server build dan harus dipastikan bahwa build berjalan di mesin ini. Ini berarti bahwa semua komponen yang bergantung harus ada di server Integrasi Berkelanjutan.
Keep the build fast- Pembangunan akan terjadi dalam beberapa menit. Proses build tidak memakan waktu berjam-jam, karena ini berarti langkah-langkah build tidak dikonfigurasi dengan benar.
Test in a clone of the production environment- Lingkungan bangunan harus dekat dengan lingkungan produksi. Jika ada perbedaan besar di antara lingkungan ini, maka ada kemungkinan build gagal dalam produksi meskipun diteruskan di server build.
Everyone can see what is happening - Keseluruhan proses pembuatan dan pengujian dan penerapan harus dapat dilihat oleh semua.
Automate deployment- Integrasi Berkelanjutan mengarah ke penerapan Berkelanjutan. Sangatlah penting untuk memastikan bahwa build harus mudah diterapkan ke lingkungan pementasan atau produksi.
Berikut adalah daftar persyaratan paling signifikan untuk Integrasi Berkelanjutan.
Check-In Regularly- Praktik terpenting agar integrasi berkelanjutan berfungsi dengan baik adalah sering melakukan check-in ke trunk atau jalur utama repositori kode sumber. Kode check-in harus dilakukan setidaknya beberapa kali sehari. Melakukan check-in secara teratur membawa banyak manfaat lainnya. Itu membuat perubahan lebih kecil dan dengan demikian kecil kemungkinannya untuk merusak build. Ini berarti versi terbaru dari perangkat lunak yang akan dikembalikan diketahui saat terjadi kesalahan dalam pembuatan berikutnya.
Ini juga membantu untuk lebih disiplin tentang refactoring kode dan untuk tetap berpegang pada perubahan kecil yang menjaga perilaku. Ini membantu memastikan bahwa perubahan yang mengubah banyak file cenderung tidak menimbulkan konflik dengan pekerjaan orang lain. Ini memungkinkan pengembang untuk lebih eksploratif, mencoba ide dan membuangnya dengan kembali ke versi komitmen terakhir.
Create a Comprehensive Automated Test Suite- Jika Anda tidak memiliki rangkaian pengujian otomatis yang komprehensif, build yang lolos hanya berarti bahwa aplikasi dapat dikompilasi dan dirakit. Meskipun bagi beberapa tim, ini merupakan langkah besar, penting untuk memiliki beberapa tingkat pengujian otomatis untuk memberikan keyakinan bahwa aplikasi Anda benar-benar berfungsi.
Biasanya, ada 3 jenis pengujian yang dilakukan di Continuous Integration yaitu unit tests, component tests, dan acceptance tests.
Pengujian unit ditulis untuk menguji perilaku bagian-bagian kecil aplikasi Anda secara terpisah. Mereka biasanya dapat dijalankan tanpa memulai seluruh aplikasi. Mereka tidak mengenai database (jika aplikasi Anda memilikinya), filesystem, atau jaringan. Mereka tidak membutuhkan aplikasi Anda untuk dijalankan dalam lingkungan seperti produksi. Pengujian unit harus berjalan sangat cepat - seluruh rangkaian Anda, bahkan untuk aplikasi besar, harus dapat berjalan dalam waktu kurang dari sepuluh menit.
Pengujian komponen menguji perilaku beberapa komponen aplikasi Anda. Seperti pengujian unit, pengujian tersebut tidak selalu mengharuskan memulai seluruh aplikasi. Namun, mereka mungkin mengenai database, filesystem, atau sistem lain (yang mungkin dimatikan). Pengujian komponen biasanya membutuhkan waktu lebih lama untuk dijalankan.
Keep the Build and Test Process Short - Jika terlalu lama untuk membangun kode dan menjalankan tes unit, Anda akan mengalami masalah berikut.
Orang-orang akan berhenti melakukan full build dan akan menjalankan tes sebelum mereka check-in. Anda akan mulai mendapatkan lebih banyak build yang gagal.
Proses Integrasi Berkelanjutan akan memakan waktu sangat lama sehingga beberapa komit akan terjadi pada saat Anda dapat menjalankan build lagi, sehingga Anda tidak akan tahu check-in mana yang merusak build.
Orang-orang akan lebih jarang check-in karena mereka harus duduk lama menunggu software dibangun dan tes dijalankan.
Don’t Check-In on a Broken Build- Kesalahan terbesar dari integrasi berkelanjutan adalah memeriksa build yang rusak. Jika build rusak, pengembang yang bertanggung jawab menunggu untuk memperbaikinya. Mereka mengidentifikasi penyebab kerusakan secepat mungkin dan memperbaikinya. Jika kita mengadopsi strategi ini, kita akan selalu berada pada posisi terbaik untuk mencari tahu penyebab kerusakan dan segera memperbaikinya.
Jika salah satu kolega kami telah melakukan check-in dan akibatnya merusak build tersebut, maka agar memiliki kesempatan terbaik untuk memperbaikinya, mereka harus menjelaskan masalahnya dengan jelas. Jika aturan ini dilanggar, build pasti membutuhkan waktu lebih lama untuk diperbaiki. Orang-orang terbiasa melihat bangunan rusak, dan dengan sangat cepat Anda masuk ke situasi di mana bangunan tersebut tetap rusak sepanjang waktu.
Always Run All Commit Tests Locally Before Committing- Selalu pastikan bahwa pengujian yang dirancang untuk aplikasi dijalankan terlebih dahulu di komputer lokal sebelum menjalankannya di server CI. Ini untuk memastikan kasus uji yang tepat ditulis dan jika ada kegagalan dalam proses CI, itu karena hasil uji yang gagal.
Take Responsibility for All Breakages that Result from Your Changes- Jika Anda melakukan perubahan dan semua pengujian yang Anda tulis lulus, tetapi pengujian lainnya gagal, build tersebut masih rusak. Biasanya ini berarti Anda telah memasukkan bug regresi ke dalam aplikasi. Itu adalah tanggung jawab Anda - karena Anda membuat perubahan - untuk memperbaiki semua tes yang tidak lulus sebagai akibat dari perubahan Anda. Dalam konteks CI ini nampaknya jelas, tetapi sebenarnya ini bukan praktik umum di banyak proyek.
Ada berbagai alat pembuatan yang tersedia untuk berbagai bahasa pemrograman. Beberapa alat build paling populer termasukAnt for Java dan MSBuild for .NET. Menggunakan alat skrip yang dirancang khusus untuk membuat perangkat lunak, bukan kumpulan skrip shell atau batch khusus, adalah cara paling efektif untuk mengembangkan solusi build yang konsisten dan dapat diulang.
Jadi mengapa kita membutuhkan proses membangun untuk memulai. Sebagai permulaan, untuk server Integrasi Berkelanjutan, proses pembuatan harus mudah dikerjakan dan harus mulus untuk diterapkan.
Mari kita ambil contoh sederhana seperti apa tampilan file build untuk .Net -
<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name = "Build">
<Message Text = "Building Project" />
<MSBuild Projects = "project.csproj" Targets = "Build/>"
</Target>
</project>Aspek-aspek berikut perlu diperhatikan tentang kode di atas -
Target ditentukan dengan nama Build. Dimana, target adalah kumpulan langkah-langkah logis yang perlu dilakukan dalam proses pembangunan. Anda dapat memiliki beberapa target dan memiliki ketergantungan antar target.
Di target kami, kami menyimpan pesan opsi yang akan ditampilkan saat proses build dimulai.
Itu MSBuild task digunakan untuk menentukan proyek .Net mana yang perlu dibangun.
Contoh di atas adalah kasus file build yang sangat sederhana. Dalam Integrasi Berkelanjutan, dipastikan bahwa file ini selalu diperbarui untuk memastikan bahwa seluruh proses pembuatan berjalan mulus.
Membangun Solusi di .Net
Alat build default untuk .Net adalah MSBuild dan merupakan sesuatu yang disertakan dengan framework .Net. Bergantung pada kerangka kerja di sistem Anda, Anda akan memiliki versi MSbuild yang relevan tersedia. Sebagai contoh, jika Anda memiliki .NET framework diinstal di lokasi default, Anda akan menemukanMSBuild.exe file di lokasi berikut -
C:\Windows\Microsoft.NET\Framework\v4.0.30319Mari kita lihat bagaimana kita bisa membangun proyek sampel kita. Mari kita asumsikan proyek Sampel kami terletak di folder bernamaC:\Demo\Simple.
Untuk menggunakan MSBuild untuk membangun solusi di atas, kita perlu membuka command prompt dan menggunakan opsi MSBuild seperti yang ditunjukkan pada program berikut.
msbuild C:\Demo\Simple\Simple.csprojDalam contoh di atas, csprojadalah file proyek yang dikhususkan untuk .Net. File csproj berisi semua informasi yang relevan untuk memastikan bahwa informasi yang diperlukan ada agar perangkat lunak dapat dibangun dengan benar. Berikut adalah tangkapan layar dari output perintah MSBuild.
Anda tidak perlu khawatir tentang peringatan keluaran selama Build berhasil dan tidak ada kesalahan.
Sekarang mari kita lihat aspek tertentu dari file MSBuild untuk melihat apa artinya. Aspek-aspek ini penting untuk diketahui dari Siklus Integrasi Berkelanjutan.
Skrip build digunakan untuk membuat solusi yang akan menjadi bagian dari seluruh siklus Integrasi berkelanjutan. Mari kita lihat skrip build umum yang dibuat sebagai bagian dari Visual Studio di.Netuntuk solusi sampel kami. Skrip build adalah yang cukup besar, bahkan untuk solusi sederhana, jadi kita akan membahas bagian terpentingnya. Secara default, skrip build akan disimpan dalam file dengan nama yang sama sebagai solusi utama di Visual Studio. Jadi dalam kasus kami, jika Anda membuka file tersebutSimple.csproj, Anda akan melihat semua pengaturan yang akan digunakan untuk membangun solusi.
Ketergantungan pada versi MSBuild yang digunakan - Pengaturan berikut akan menggunakan file MSBuild yang diinstal di server CI.
<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''">
$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
WebApplications\Microsoft.WebApplication.targets" Condition = "false" />File apa yang diperlukan untuk membangun solusi dengan benar - ItemGrouptag akan berisi semua file .Net yang diperlukan yang diperlukan agar proyek berhasil dibangun. File-file ini harus ditempatkan di server build yang sesuai.
<ItemGroup>
<Reference Include = "Microsoft.CSharp" />
<Reference Include = "System.Web.DynamicData" />
<Reference Include = "System.Web.Entity" />
<Reference Include = "System.Web.ApplicationServices" />
<Reference Include = "System.ComponentModel.DataAnnotations" />
<Reference Include = "System" />
<Reference Include = "System.Data" />
<Reference Include = "System.Core" />
<Reference Include = "System.Data.DataSetExtensions" />
<Reference Include = "System.Web.Extensions" />
<Reference Include = "System.Xml.Linq" />
<Reference Include = "System.Drawing" />
<Reference Include = "System.Web" />
<Reference Include = "System.Xml" />
<Reference Include = "System.Configuration" />
<Reference Include = "System.Web.Services" />
<Reference Include = "System.EnterpriseServices"/>
</ItemGroup>Apa pengaturan server Web yang akan digunakan - Saat kita mengunjungi topik Penyebaran Berkelanjutan, Anda akan melihat bagaimana MSBuild akan digunakan untuk mengganti pengaturan ini dan menerapkannya ke server pilihan kami.
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>Langkah penting berikutnya adalah memastikan bahwa solusi dibangun di atas server build. Bagian pertama adalah langkah manual, karena sebelum alat integrasi berkelanjutan digunakan, pertama-tama kita harus memastikan bahwa build dijalankan di server build dengan cara yang sama seperti yang dilakukan di mesin klien. Untuk melakukan ini, kita harus menerapkan langkah-langkah berikut -
Step 1- Salin seluruh file solusi ke server. Kami telah membuat server instans Amazon yang akan digunakan sebagai server build kami. Jadi, lakukan salinan manual ke seluruh server.Net solusi ke server.
Step 2- Pastikan kerangka kerja ada di server. Jika Anda telah mengkompilasi aplikasi Anda dalam .Net framework 4.0 pada mesin klien Anda, Anda harus memastikan bahwa aplikasi tersebut juga diinstal pada mesin server. Jadi pergilah ke lokasiC:\Windows\Microsoft.NET\Framework di server Anda dan memastikan kerangka kerja yang diinginkan ada.
Step 3 - Sekarang mari kita jalankan MSBuild di server dan lihat apa yang terjadi.
Oke, jadi sepertinya kita mengalami kesalahan. Ada satu pelajaran penting dalam Integrasi Berkelanjutan dan Anda perlu memastikan bahwa Build berfungsi di server build. Untuk ini, Anda perlu memastikan bahwa semua perangkat lunak prasyarat diinstal pada server build.
Untuk .Net, kita perlu menginstal komponen bernama Visual Studio Redistributable package. Paket ini berisi semua file yang diperlukan yang diperlukan untuk file.Netaplikasi untuk dibangun di server. Jadi mari kita lakukan langkah-langkah instalasi berikut di server build.
Step 4 - Klik dua kali file yang dapat dieksekusi untuk memulai instalasi.
Step 5 - Pada langkah berikutnya, setujui Persyaratan Lisensi dan klik Instal.
Step 6 - Sekarang saat menjalankan MSBuild, kami perlu memastikan bahwa kami menyertakan parameter tambahan saat memanggil MSBuild yaitu - p:VisualStudioversion = 12.0. Ini memastikan bahwa MSBuild mereferensikan file yang diunduh pada langkah sebelumnya.
Sekarang kita dapat melihat bahwa solusi telah dibangun dengan benar dan kita juga tahu proyek dasar kita dibangun dengan benar di server.
Aspek kunci berikutnya adalah memastikan kode dasar kami diperiksa ke server manajemen repositori kode sumber kami yaitu Git. Untuk melakukan ini, kita perlu mengikuti langkah-langkah berikut.
Step 1- Inisialisasi repositori agar dapat diunggah ke Git. Ini dilakukan dengangitperintah init. Jadi, Anda harus pergi ke folder proyek Anda dan menerbitkan filegit init perintah.
Step 2- Langkah selanjutnya disebut pementasan file di Git. Ini mempersiapkan semua file di folder proyek, yang perlu ditambahkan ke Git. Anda melakukan ini dengangit addperintah seperti yang ditunjukkan pada tangkapan layar berikut. '.' notasi digunakan untuk mengatakan bahwa semua file dalam direktori dan subdirektori harus disertakan dalam komit.
Step 3 - Langkah terakhir adalah memasukkan file ke repositori Git, sehingga sekarang menjadi repositori Git yang lengkap.
Sekarang kita memiliki kode sumber di repositori Git dan semua kode awal kita bekerja di server build, sekarang saatnya untuk membuat proyek di server Integrasi Berkelanjutan kita. Ini dapat dilakukan melalui langkah-langkah berikut -
Step 1- Login ke perangkat lunak TeamCity. Buka url di server Integrasi Berkelanjutan Anda -http://localhost:8080/login.html.
Masukkan kredensial admin dan masuk ke server.
Step 2- Setelah masuk, Anda akan disajikan dengan layar beranda. KlikCreate Project untuk memulai proyek baru.
Step 3- Beri nama proyek dan klik Buat untuk memulai proyek. Dalam kasus kami, kami memberi nama sebagai 'Demo' untuk proyek kami seperti yang ditunjukkan pada tangkapan layar berikut.
Step 4- Langkah selanjutnya adalah menyebutkan repositori Git yang akan digunakan dalam proyek kami. Ingatlah bahwa dalam lingkungan Integrasi Berkelanjutan, server CI perlu mengambil kode dari repositori berkemampuan Git. Kami telah mengaktifkan folder proyek kami menjadi repositori yang mendukung Git pada langkah sebelumnya. Di TeamCity, Anda perlu membuat root VCS. Untuk ini, klikVCS Roots di layar utama proyek.
Step 5 - Di layar yang muncul berikutnya, klik Create VCS root seperti yang ditunjukkan pada tangkapan layar berikut.
Step 6 - Di layar berikutnya yang muncul, lakukan langkah-langkah berikut -
Sebutkan jenis VCS sebagai Git.
Beri nama untuk root VCS, ini bisa nama apa saja. Kami telah memberi nama sebagaiApp.
Berikan url Ambil sebagai C:\Demo\Simple - Ini adalah out git repositori diaktifkan.
Jika Anda menggulir ke bawah layar, Anda akan mendapatkan tombol Uji koneksi. Klik untuk memastikan bahwa Anda berhasil terhubung ke repositori berkemampuan Git.
Step 7 - Klik Buat dan Anda sekarang akan melihat repositori Anda terdaftar seperti yang ditunjukkan pada gambar berikut.
Step 8- Langkah selanjutnya adalah membuat konfigurasi build yang akan digunakan untuk membangun proyek. Buka layar proyek Anda diTeamCity → General Settings. Klik Buat Konfigurasi Bangun.
Step 9- Pada layar berikut, beri nama untuk Build Configuration. Dalam kasus kami, kami menamakannya sebagaiDemoBuild lalu klik Buat.
Step 10 - Di layar berikutnya yang muncul, Anda akan diminta untuk memilih VCS repositoryyang dibuat pada langkah sebelumnya. Jadi pilihlah namanya‘App’ dan klik Lampirkan.
Step 11- Sekarang di layar berikutnya yang muncul, kita perlu mengkonfigurasi langkah-langkah pembuatan. Jadi klik 'configure build steps manually'hyperlink.
Step 12 - Di layar pembuatan berikutnya, kita perlu memasukkan detail berikut -
Pilih tipe Runner sebagai MSBuild.
Berikan nama opsional untuk nama langkah.
Beri nama file yang ingin dibangun. Ketika kami menentukan MSbuild di bagian sebelumnya, kami biasanya melihat bahwa kami memberikan opsiSimple.csproj. Hal yang sama perlu ditentukan di sini.
Pilih versi MSBuild sebagai 'Microsoft Build Tools 2013'.
Memilih MSBuild ToolsVersion sebagai 12.0.
Gulir ke bawah halaman untuk menyimpan pengaturan.
Step 13 - Di layar berikutnya, klik Jalankan.
Anda akan melihat pembuatan aplikasi Anda sekarang sedang berlangsung.
Anda harus mendapatkan layar yang sukses, yang merupakan pertanda baik bahwa solusi Anda berjalan dengan baik.
Anda juga dapat membuka log build Anda untuk melihat semua langkah yang dicakup oleh server Integrasi Berkelanjutan seperti yang ditunjukkan pada gambar layar berikut.
Sekarang setelah kita memiliki kode dasar di Git dan tautan ke server Integrasi Berkelanjutan, akhirnya saatnya untuk melihat langkah pertama Integrasi Berkelanjutan dalam tindakan. Ini dilakukan dengan menentukan tugas di server Integrasi Berkelanjutan seperti pemicu, yang membuat seluruh Proses Integrasi Berkelanjutan berjalan semulus mungkin. Mari buat perubahan pada kode kita di Visual Studio.
Step 1 - Pergi ke Demo.aspx halaman di Visual Studio dan buat perubahan pada judul halaman.
Step 2 - Jika kita menanyakan repositori Git kita melalui git status perintah, Anda sebenarnya akan melihat bahwa file Demo.aspx file telah diubah.
Sekarang kami perlu memastikan bahwa setiap perubahan dalam kode kami harus memicu build di server integrasi berkelanjutan kami. Untuk ini kita perlu melakukan perubahan berikut.
Step 3 - Buka dasbor proyek Anda dan klik bagian pemicu dan klik Add new trigger.
Step 4 - Di layar berikutnya yang muncul, pilih VCS trigger, yang akan digunakan untuk membuat pemicu sehingga saat check-in dilakukan ke repositori, build akan dipicu.
Step 5 - Klik Show Advanced Options dan pastikan opsi yang ditunjukkan pada tangkapan layar berikut dipilih.
Step 6- Klik Simpan. Anda sekarang akan melihat pemicu berhasil terdaftar seperti yang ditunjukkan pada tangkapan layar berikut.
Step 7- Sekarang saatnya untuk memeriksa kode kita ke dalam repositori Git dan melihat apa yang terjadi. Jadi mari kita pergi ke command prompt dan mengeluarkan filegit add perintah untuk menampilkan file yang diubah.
Step 8 - Sekarang keluarkan git commit perintah, dan itu akan mendorong perubahan ke dalam repositori Git.
Step 9 - Jika sekarang Anda masuk ke layar Ikhtisar Proyek, Anda sekarang akan melihat bangunan baru akan dipicu dan dijalankan.
Jika Anda melihat Change log Tab, Anda akan melihat git comment yang memicu build.
Ayo coba sekali lagi. Mari buat perubahan lain padaDemo.aspxmengajukan. Mari kita lakukan agit add perintah dan a git commit perintah dengan pesan komit berikut.
Sekarang Anda akan melihat sebuah build dipicu secara otomatis di dasbor Project di TeamCity.
Bangunan tersebut akan menampilkan pesan sukses.
Anda sekarang akan melihat pesan 'Komitmen kedua' yang digunakan saat perubahan dilakukan ke git repository.
Kami sekarang telah berhasil menyelesaikan bagian pertama dari proses Integrasi Berkelanjutan.
Notifikasi Kegagalan Build adalah peristiwa yang dipicu setiap kali build gagal. Notifikasi dikirim ke semua orang penting setiap kali build gagal. Hal penting pertama yang harus dilakukan dalam kasus seperti itu adalah memastikan waktu yang dihabiskan untuk build yang gagal untuk memastikan build berhasil. Langkah-langkah berikut digunakan untuk memastikan bahwa notifikasi build diterapkan di TeamCity.
Berikut adalah langkah-langkah untuk mengatur notifikasi email di TeamCity.
Step 1- Di TeamCity, buka dasbor Proyek Anda, klik Administrasi di pojok kanan atas. Anda kemudian akan melihat fileEmail Notifiertautan di sisi kiri. Klik tautan ini untuk menampilkan pengaturan umum untuk Email.
Step 2 - Langkah selanjutnya adalah memasukkan detail yang valid SMTP Server. Gmail menyediakan fasilitas SMTP gratis, yang bisa digunakan oleh siapa saja. Jadi kita bisa memasukkan detail itu di layar berikutnya yang muncul seperti yang ditunjukkan pada tangkapan layar berikut.
- Host SMTP - smtp.gmail.com
- Port SMTP no - 465
- Kirim pesan email dari dan login SMTP - Ini harus merupakan ID Gmail yang valid
- Kata sandi SMTP - Kata sandi yang valid untuk id Gmail itu
- Koneksi aman - Jadikan ini sebagai SSL
Step 3 - Klik Test Connectionhanya untuk memastikan bahwa pengaturan berfungsi dengan benar. Lalu klikSave untuk menyimpan pengaturan.
Step 4- Langkah selanjutnya adalah mengaktifkan notifikasi build untuk pengguna. Tugas pertama adalah membuat pengguna yang akan menerima notifikasi build ini. Buka dasbor proyek Anda dan pilihUsers Option.
Step 5- Buat pengguna baru. Masukkan nama pengguna dan kata sandi yang diperlukan. Kemudian Klik tombol Buat Pengguna, yang terletak di bagian bawah layar.
Step 6 - Sekarang login ke sistem TeamCity dengan id pengguna dan kata sandi baru ini.
Step 7- Setelah Anda masuk, Anda akan disajikan dengan pengaturan Umum pengguna. Di bagian Email Notifier, klik Edit.
Step 8 - Di layar berikutnya yang muncul, klik Add new rule.
Step 9 - Di Tambahkan aturan baru, pilih dua opsi berikut, lalu klik Simpan.
Dibangun dari proyek tertentu - Pilih proyek Demo.
Aktifkan kotak centang untuk 'Build gagal'.
Dengan mengaktifkan dua opsi ini, sekarang setiap kali build gagal untuk proyek Demo, pemberitahuan email akan dikirim ke pengguna - demouser.
Step 10- Sekarang mari kita picu build yang salah untuk melihat ini beraksi. Di Visual Studio, buka filedemo.aspx.cs mengajukan dan menambahkan baris kode yang salah.
Step 11 - Sekarang periksa kode dari Git dengan melakukan a git add dan git commit.
Sekarang di Dasbor Proyek, pembangunan akan secara otomatis dipicu dan Anda akan melihat bahwa pembangunan akan gagal seperti yang ditunjukkan pada tangkapan layar berikut.
Jika Anda masuk ke ID Gmail dari demouser, Anda benar-benar akan melihat pemberitahuan kegagalan build di dalamnya seperti yang ditunjukkan pada tangkapan layar berikut.
Salah satu aspek kunci dari Integrasi Berkelanjutan adalah selalu melihat performa build, mengumpulkan metrik penting, mendokumentasikan hasil tersebut, dan menghasilkan umpan balik berkelanjutan melalui build berkelanjutan.
Apa manfaat memiliki metrik ini?
Not Committing Code Enough- Jika pengembang tidak sering memasukkan kode ke repositori kontrol versi, alasannya mungkin karena build integrasi yang lambat. Untuk mulai mengurangi durasi build, lakukan analisis tingkat tinggi dari lingkungan build integrasi untuk menentukan bottleneck.
Selanjutnya, analisis temuan dan tentukan peningkatan yang paling sesuai, lalu coba lakukan perubahan dalam proses build untuk mengurangi durasi build. Terakhir, evaluasi ulang durasi build untuk menentukan apakah perbaikan lebih lanjut diperlukan.
Improve Test Performance- Bahkan dalam sistem CI yang berfungsi dengan baik, sebagian besar waktu build integrasi akan digunakan oleh pelaksanaan pengujian otomatis. Mengevaluasi dan meningkatkan performa pengujian ini dapat mengurangi durasi build secara drastis.
Infrastructure Issues- Anda mungkin menemukan bahwa build integrasi lambat karena infrastruktur sistem. Mungkin kinerja jaringan lambat atau ada koneksi jaringan pribadi virtual yang berkinerja lambat.
Sistem yang tersebar secara geografis dan perangkat keras atau perangkat lunak yang tidak dapat diandalkan juga dapat menyebabkan masalah kinerja. Selidiki dan tingkatkan sumber daya infrastruktur apa pun untuk mengurangi durasi pembangunan.
Metrik
Berikut adalah beberapa metrik yang tersedia di server Integrasi Berkelanjutan.
Mari kita lihat apa yang ditawarkan TeamCity -
Salah satu bentuk metrik yang paling sederhana adalah yang tersedia di dasbor proyek. Elemen kuncinya di sini adalah mencatat durasi setiap build. Jika durasi setiap build mulai meningkat secara tidak proporsional dengan kode yang sedang dibuat, ini bisa menjadi masalah. Jadi, ini adalah salah satu umpan balik yang dapat diambil dan penyebabnya mungkin karena server CI memiliki sumber daya yang rendah dan mungkin kapasitas server perlu ditingkatkan.
TeamCity memiliki fasilitas untuk melihat apakah server CI sebenarnya mengalami masalah apa pun yang berkaitan dengan infrastruktur. Dalamadmin dashboard di TeamCity, seseorang dapat mengklik Disk Usage untuk melihat berapa banyak ruang disk yang digunakan oleh setiap build.
Jika ada detail lebih lanjut yang diperlukan, maka TeamCity memiliki diagnostics button, yang dapat memberikan lebih banyak informasi tentang CPU and Memory sedang digunakan oleh CI Server.
Tampilan Detail Metrik Build
Jika seseorang ingin melihat tampilan mendetail dari pembangunan proyek tertentu dari waktu ke waktu, maka ini tersedia sebagai bagian dari pembangunan proyek. Di layar pembuatan Proyek, buka layar Statistik, ini akan memberikan berbagai statistik dan bagan tentang bagaimana bangunan itu bekerja.
Salah satu fitur utama dari Continuous Integration adalah memastikan bahwa on-going testingmenampung semua kode yang dibangun oleh server CI. Setelah build dilakukan oleh CI Server, harus dipastikan bahwa kasus pengujian sudah siap untuk mendapatkan kode yang diperlukan yang diuji. Setiap server CI memiliki kemampuan untuk menjalankan kasus pengujian unit sebagai bagian dariCI suite. Di.Net, pengujian unit adalah fitur yang ada di dalam file .Net framework dan hal yang sama juga dapat dimasukkan ke dalam CI Server.
Bab ini akan melihat bagaimana kita dapat mendefinisikan kasus uji di .Netdan kemudian biarkan server TeamCity kami menjalankan kasus uji ini setelah pembuatan selesai. Untuk ini, pertama-tama kami perlu memastikan bahwa kami memiliki pengujian unit yang ditentukan untuk proyek sampel kami.
Untuk melakukan ini, kita harus mengikuti langkah-langkah selanjutnya dengan sangat hati-hati.
Step 1- Mari tambahkan kelas baru ke solusi kita, yang akan digunakan dalam Uji Unit kita. Kelas ini akan memiliki variabel nama, yang akan menampung string "Integrasi Berkelanjutan". String ini akan ditampilkan di halaman web. Klik kanan pada Simple Project dan pilih opsi menuAdd → Class.
Step 2 - Beri nama kelas sebagai Tutorial.cs dan klik tombol Tambah di bagian bawah layar.
Step 3- Buka file Tutorial.cs dan tambahkan kode berikut di dalamnya. Kode ini hanya membuat string yang disebutName, dan di Konstruktor tetapkan nama ke nilai string sebagai Continuous Integration.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace Simple {
public class Tutorial {
public String Name;
public Tutorial() {
Name = "Continuous Integration";
}
}
}Step 4 - Mari kita ubah Demo.aspx.csfile untuk menggunakan kelas baru ini. Perbarui kode dalam file ini dengan kode berikut. Jadi kode ini sekarang akan membuat instance baru dari kelas yang dibuat di atas.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace Simple {
public partial class Demo : System.Web.UI.Page {
Tutorial tp = new Tutorial();
protected void Page_Load(object sender, EventArgs e) {
tp.Name = "Continuous Integration";
}
}
}Step 5 - Di kami demo.aspx file, mari kita sekarang mereferensikan tp.Name variabel, yang dibuat di aspx.cs mengajukan.
<%@ Page Language = "C#" AutoEventWireup = "true"
CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
<head runat = "server">
<title>TutorialsPoint1</title>
</head>
<body>
<form id = "form1" runat = "server">
<div>
<% = tp.Name%>)
</div>
</form>
</body>
</html>Hanya untuk memastikan kode kami berfungsi dengan baik dengan perubahan ini, Anda dapat menjalankan kode di Visual Studio. Anda harus mendapatkan keluaran berikut setelah kompilasi selesai.
Step 6- Sekarang saatnya menambahkan pengujian Unit kami ke proyek. Klik kananSolution dan pilih opsi menu Add → New Project.
Step 7 - Arahkan ke Test dan di sisi kanan, pilih Unit Test Project. Beri nama sebagaiDemoTest lalu klik OK.
Step 8 - Di Demo Test project, Anda perlu menambahkan referensi ke proyek Sederhana dan yang diperlukan testing assemblies. Klik kanan pada proyek dan pilih opsi menuAdd Reference.
Step 9 - Di layar berikutnya yang muncul, buka Proyek, pilih Simple Reference dan klik OK.
Step 10 - Klik Add Reference sekali lagi, pergi ke Assemblies dan ketik Webdi kotak Pencarian. Kemudian tambahkan referensiSystem.Web.
Step 11 - Di Unit Test file, tambahkan kode berikut. Kode ini akan memastikan bahwa kelas Tutorial memiliki variabel nama string. Ini juga akan menegaskan fakta bahwa Nama harus sama dengan nilai "Integrasi Berkelanjutan". Ini akan menjadi kasus Uji sederhana kami.
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;
namespace DemoTest {
[TestClass]
public class UnitTest1 {
[TestMethod]
public void TestMethod1() {
Tutorial tp = new Tutorial();
Assert.AreEqual(tp.Name, "Continuous Integration");
}
}
}Step 12- Sekarang mari kita jalankan pengujian kita di Visual Studio untuk memastikannya berfungsi. Di Visual Studio, pilih opsi menuTest → Run → All Tests.
Setelah menjalankan tes, Anda akan melihat Tes berhasil dijalankan di sisi kiri Visual Studio.
Mengaktifkan Pengujian Berkelanjutan dalam TeamCity - Sekarang semua kasus pengujian sudah ada, sekarang saatnya untuk mengintegrasikan ini ke server Team City kami.
Step 13- Untuk ini, kita perlu membuat langkah pembangunan dalam konfigurasi Proyek kita. Pergi ke rumah proyek Anda dan klik Edit Pengaturan Konfigurasi.
step 14 - Lalu pergi ke Build Step → MS Build dan klik Add build step seperti yang digambarkan pada tangkapan layar berikut.
Di layar berikutnya yang muncul, tambahkan nilai berikut -
Pilih jenis pelari sebagai Tes Visual Studio.
Masukkan nama langkah Tes opsional.
Pilih jenis Mesin Uji sebagai VSTest.
Pilih versi Mesin Uji sebagai VSTest2013.
Dalam nama File pengujian, berikan lokasi sebagai DemoTest\bin\Debug\DemoTest.dll - Ingat bahwa DemoTestadalah nama proyek kami yang berisi Tes Unit kami. ItuDemoTest.dll akan dihasilkan oleh langkah pembuatan pertama kami.
Klik Simpan yang akan tersedia di ujung layar.
Sekarang Anda akan memiliki 2 langkah membangun untuk proyek Anda. Yang pertama adalah langkah Build yang akan membuat kode aplikasi dan proyek pengujian Anda. Dan selanjutnya akan digunakan untuk menjalankan kasus uji Anda.
Step 15- Sekarang saatnya untuk memeriksa semua kode Anda di Git, sehingga seluruh proses pembuatan dapat dipicu. Satu-satunya perbedaan adalah kali ini, Anda perlu menjalankan filegit add dan git commit perintah dari Demo parent folder seperti yang ditunjukkan pada tangkapan layar berikut.
Sekarang ketika build dipicu, Anda akan melihat keluaran awal yang akan mengatakan bahwa pengujian berhasil.
Step 16 - Jika Anda mengklik hasil Tes lulus dan pergi ke tab Tes, Anda sekarang akan melihat bahwa UnitTest1 telah dieksekusi dan lulus.
Pemeriksaan Berkelanjutan adalah proses peninjauan kode otomatis dari pemeriksaan yang dilakukan untuk kode Anda sebelum pengujian yang sebenarnya dijalankan. Ada perbedaan halus antara memeriksa dan menguji perangkat lunak. Pengujian bersifat dinamis dan menjalankan perangkat lunak untuk menguji fungsionalitasnya. Inspeksi menganalisis kode berdasarkan sekumpulan aturan yang telah ditentukan sebelumnya.
Pengawas (atau alat analisis statis dan dinamis) diarahkan oleh standar teridentifikasi yang harus dipatuhi oleh tim (biasanya metrik pengkodean atau desain). Contoh target inspeksi mencakup pengkodean standar "tata bahasa", kepatuhan pelapisan arsitektural, duplikasi kode, dan banyak lainnya.
Inspeksi Berkelanjutan mengurangi waktu antara penemuan dan perbaikan. Ada sejumlah alat Inspeksi Berkelanjutan yang tersedia. Untuk contoh ini, kami akan menggunakanNCover 3.xyang memiliki integrasi dengan TeamCity. Mari kita lihat bagaimana kita dapat melakukan Inspeksi Berkelanjutan dan apa yang dapat dilakukannya untuk kita.
Unduh dan Instal NCover
NCover adalah produk terpisah yang perlu diunduh dan dipasang. Untuk mengunduh NCover, silakan klik tautan berikut dan unduh penginstal 32-bit -http://www.ncover.com/info/download.
Jalankan penginstal yang diunduh lalu klik Berikutnya setelah penginstal dimulai.
Terima perjanjian Lisensi dan kemudian klik Berikutnya.
Terima komponen default dan klik Next.
Klik pada tombol Install untuk memulai instalasi.
Klik tombol Selesai untuk menyelesaikan penginstalan.
Luncurkan penginstalan NCover untuk pertama kalinya dengan mengunjungi C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Anda hanya perlu menginstal kunci uji coba untuk pertama kalinya, yang merupakan proses yang mudah.
Konfigurasikan Proyek di TeamCity untuk Menggunakan NCover
Step 1 - Buka layar beranda proyek Anda dan klik Edit Pengaturan Konfigurasi.
Step 2 - Pergi ke Build Steps dan klik Edit untuk TestStep. Pemeriksaan Berkelanjutan perlu dijalankan bersama dengan pengujian Unit yang ditentukan.
Step 3 - Di bagian Cakupan Bersih, klik .Net Coverage Tool. Dan kemudian pilih pengaturan berikut.
- Pilih alat. Cakupan Bersih sebagai NCover (3.x)
- Platform sebagai x86
- Versi sebagai v4.0
- Path ke NCover sebagai C: \ Program Files (x86) \ NCover
- Biarkan pengaturan lain apa adanya
Step 4 - Klik Simpan.
Step 5 - Sekarang masuk ke layar utama proyek Anda dan klik Jalankan.
Step 6- Setelah build dijalankan, klik Tes lulus. Anda sekarang akan melihat layar Cakupan Kode dan Anda akan melihat banyak indikator metrik.
Step 7 - Sekarang Anda dapat mengklik tab Cakupan Kode untuk mendapatkan informasi lebih lanjut tentang Analisis Kode.
Step 8 - Klik fullcoveragereport.html. Anda sekarang akan mendapatkan laporan komprehensif lengkap tentang pemeriksaan yang dilakukan untuk.Net code.
Continuous Database Integration adalah proses membangun kembali database Anda dan menguji data setiap kali ada perubahan yang diterapkan ke repositori kontrol versi proyek.
Dalam Integrasi Database, umumnya semua artefak yang terkait dengan integrasi database -
- Harus berada dalam sistem kontrol versi.
- Dapat diuji ketelitiannya dan diinspeksi untuk kepatuhan kebijakan.
- Dapat dibuat menggunakan skrip build Anda.
Aktivitas yang dapat dilibatkan dalam Continuous Database Integration dapat berupa salah satu dari berikut ini -
Drop a Database - Jatuhkan database dan hapus data terkait, sehingga Anda dapat membuat database baru dengan nama yang sama
Create a new Database - Buat database baru menggunakan Data Definition Language (DDL).
Insert the Initial Data - Masukkan data awal apa pun (mis., Tabel pencarian) yang diharapkan ada di sistem Anda saat dikirim.
Migrate Database and Data - Migrasikan skema database dan data secara berkala (jika Anda membuat sistem berdasarkan database yang sudah ada).
Modify Column Attributes - Memodifikasi atribut dan batasan kolom tabel berdasarkan persyaratan dan pemfaktoran ulang.
Modify Test Data - Ubah data uji sesuai kebutuhan untuk beberapa lingkungan.
Jadi dalam contoh Continuous Database kami, kami akan melakukan langkah-langkah berikut -
Kami akan membuat database MS SQL Server dan tabel yang sesuai.
Kami akan membuat skrip dari SQL Server Management Studio. Script database ini akan digunakan untuk menyiapkan tabel kita di database.
Kami akan menulis kode di proyek ASP.Net kami untuk mengakses database ini.
Kami akan membuat langkah dalam proyek kami di TeamCity untuk menjalankan skrip ini.
Kami akan memeriksa skrip kami ke Git.
Langkah-langkah untuk melakukan ini di database AWS yang dibuat di bagian sebelumnya.
Step 1- Membuat database MS SQL Server dan tabel yang sesuai. Mari buka SQL Server Management Studio dan buat database dan tabel sederhana. Database klik kanan dan klikNew Database.
Step 2 - Beri nama sebagai Demodb dan klik OK
Step 3 - Di database baru, klik kanan dan buat tabel baru.
Step 4 - Anda dapat menambahkan kolom yang Anda inginkan ke tabel.
Step 5 - Simpan tabel dan beri nama sebagai Demotb.
Step 6 - Sekarang klik kanan pada tabel dan pilih opsi menu Script Table as → Drop and Create to → File.
Step 7 - Simpan file ke folder proyek demo sebagai Sample.sql.
Seperti inilah tampilan skrip database. Ini pertama-tama akan menjatuhkan tabel yang ada jika ada dan kemudian membuat kembali tabel tersebut.
USE [Demodb]
GO
/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM
******
DROP TABLE [dbo].[Demotb]
GO
/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Demotb](
[TutorialName] [nvarchar](max) NULL,
[TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GOStep 8 - Sekarang mari cepat ganti ASP.Net code untuk merujuk ke database baru.
Step 9 - Di Tutorial.cs file di Demo project, tambahkan baris kode berikut. Baris kode ini akan terhubung ke database Anda, mengambil versi Server dan menyimpan nama versi di variabel Name. Kita dapat menampilkan variabel Nama ini di fileDemo.aspx.cs mengajukan melalui a Response.write perintah.
using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
namespace Simple {
public class Tutorial {
public String Name;
public Tutorial() {
string connectionString = "Data Source = WIN-50GP30FGO75;
Initial Catalog = Demodb;
Integrated Security = true;";
using (SqlConnection connection = new SqlConnection()) {
connection.ConnectionString = connectionString;
connection.Open();
Name = connection.ServerVersion;
connection.Close();
}
}
}
}Step 10 - Tambahkan kode berikut ke Demo.aspx.cs file untuk memastikan bahwa ini menampilkan versi SQL Server.
using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace Simple {
public partial class Demo : System.Web.UI.Page {
Tutorial tp = new Tutorial();
protected void Page_Load(object sender, EventArgs e){
Response.Write(tp.Name);
}
}
}Sekarang jika kita menjalankan kodenya, Anda akan mendapatkan output berikut di browser.
Step 11- Sekarang mari kita tambahkan langkah kita di TeamCity yang akan memanggil skrip database. Buka dasbor proyek Anda dan klikEdit Configuration Settings.
Step 12 - Pergi ke Build Steps dan klik Add build step.
Pilih opsi berikut (Perhatikan bahwa klien MS SQL Server harus diinstal di CI Server).
Jenis runner haruslah Command Line.
Berikan Nama Langkah opsional.
Proses harus dapat dijalankan dengan parameter.
Perintah yang dapat dieksekusi harus C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe
Parameter perintah harus -S WIN-50GP30FGO75 -i Sample.sql. Dimana –S memberikan nama contoh SQL Server.
Step 13 - Klik Simpan.
Sekarang yang perlu dipastikan adalah urutan build. Anda harus memastikan urutan build adalah sebagai berikut.
Step 14 - Anda dapat mengubah urutan build dengan memilih opsi untuk menyusun ulang langkah-langkah build.
Penyiapan database harus yang pertama - Jadi ini akan digunakan untuk membuat ulang database Anda dari yang baru.
Berikutnya adalah membangun aplikasi Anda.
Akhirnya pengaturan pengujian Anda.
Step 15 - Sekarang jalankan git add dan git commit perintah sehingga Sample.sqlfile diperiksa ke Git. Ini akan memicu build secara otomatis. Dan bangunan ini harus lulus.
Anda sekarang memiliki siklus build lengkap dengan aspek integrasi database berkelanjutan juga dalam siklus Anda. Di bagian selanjutnya, mari kita bahas lebih jauh dan lihat Deployment Berkelanjutan.
Sekarang Anda telah melakukan ini dengan SQL Server lokal, kami dapat mengulangi langkah yang sama untuk file AWS MS SQLServer yang dibuat di salah satu bagian sebelumnya. Untuk menyambung ke Microsoft SQL Server, Anda harus menyambungkan melalui konvensi berikut.
Step 16- Pertama, lihat apa nama yang ditetapkan ke instans database Anda di AWS. Saat Anda masuk ke AWS, buka bagian RDS di bawah bagian database.
Step 17 - Klik Instans DB di layar berikutnya yang muncul.
step 18- Klik pada database Anda dan catat titik akhirnya. Pada tangkapan layar berikut, itudemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433
Step 19 - Sekarang untuk menyambung ke database dari SQL Server Management Studio, Anda perlu menentukan koneksi sebagai demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Perhatikan koma yang digunakan antara nama instance dan nomor port).
Tangkapan layar berikut menunjukkan koneksi yang berhasil ke database.
Kemudian Anda dapat mengulangi semua langkah yang sama. ItuSqlcmd command akan menjadi sebagai berikut -
Perintah yang sama ini dapat diganti di langkah pembuatan Database di TeamCity. Saat Anda menjalankan filesqlcmd command, tabel akan dibuat secara otomatis di database SQL Server Anda di AWS.
Build otomatis dan build berulang. Tes otomatis dan tes berulang. Kategori uji dan frekuensi uji. Inspeksi berkelanjutan. Integrasi database berkelanjutan. Rangkaian tugas ini dalam menciptakan lingkungan CI yang efektif terutama memungkinkan satu manfaat utama: merilis perangkat lunak yang berfungsi kapan saja, di lingkungan apa pun.
Di bab sebelumnya, kami telah menyelesaikan semua segmen berikut -
- Membuat kode kami.
- Memastikan build yang tepat di TeamCity.
- Membuat proses Integrasi Database.
- Melakukan pengujian yang sukses.
Sekarang satu-satunya hal yang tersisa adalah melakukan penerapan otomatis, sehingga seluruh proses kami selesai.
Untuk penerapan otomatis dalam kasus kami, kami perlu mengikuti langkah-langkah ini -
Di server penyebaran kami, pastikan bahwa IIS diinstal.
Pastikan bahwa pengguna IIS diberikan akses ke database kami.
Buat profil publikasikan yang akan digunakan untuk mempublikasikan situs saat dibuat.
Pastikan kami mengubah perintah MSBuild kami untuk melakukan penyebaran otomatis.
Otomatiskan TeamCity untuk melakukan publikasi otomatis.
Lakukan git commit untuk memastikan semua file Anda ada di Git.
Step 1- Konfigurasi Server IIS lokal. Jika Anda memiliki Server IIS lokal atau jarak jauh, konfigurasi berikut dapat dilakukan untuk menyebarkan aplikasi kita. Itu selalu merupakan praktik yang baik untuk melihat apakah penerapan dapat dilakukan secara manual sebelum dilakukan secara otomatis.
Step 2 - Pada server Windows 2012, buka Manajer Server Anda dan klik Tambah Peran dan Fitur.
Step 3 - Klik Berikutnya pada layar berikut yang muncul.
Step 4 - Pilih penginstalan berbasis peran atau berbasis fitur di layar berikutnya dan klik Berikutnya.
Step 5 - Pilih server default dan klik Berikutnya.
Step 6 - Pilih peran server Web dan klik Berikutnya.
Step 7 - Di layar berikutnya yang muncul, klik Berikutnya.
Step 8 - Klik Berikutnya lagi pada layar berikut yang muncul.
Step 9 - Di layar berikutnya yang muncul, klik Berikutnya.
Step 10 - Di layar terakhir, Anda dapat mengklik tombol Instal untuk menginstal IIS.
Setelah Anda menginstal IIS, Anda dapat membukanya dengan membuka Layanan Informasi Internet.
Step 11 - Klik Application Pools, Anda akan melihat sebuah kolam dengan nama DefaultAppPool. Ini harus memiliki akses ke SQL Server di langkah berikutnya.
Step 12 - Jika kita perlu menghubungkan aplikasi ASP.Net ke aplikasi MS SQL Server, kita harus memberikan akses ke kumpulan aplikasi default ke instance SQL Server, sehingga dapat terhubung ke Demodb database.
Step 13- Buka SQL Server Management Studio. Buka Login, klik kanan dan pilih opsi menuNew Login.
Di layar berikutnya, perbarui parameter berikut dan klik OK.
- Nama login sebagai IIS APPPOOL \ DefaultAppPool.
- Database default - Ini harus menjadi database kami, yaitu demodb.
Step 14 - Membuat Publish Profile. Profil terbitkan digunakan di Visual Studio untuk membuat paket penyebaran yang kemudian dapat digunakan dengan MS Build dan di CI Server yang sesuai. Untuk melakukan ini, dari Visual Studio, klik kanan pada proyek dan klik opsi menu Publikasikan
Step 15 - Di layar berikutnya yang muncul, pilih untuk membuat profil Publikasikan baru, beri nama - DemoDeployment. Kemudian klik tombol Next.
Di layar berikutnya yang muncul, tambahkan nilai berikut -
- Pilih metode Publikasikan sebagai Penerapan Web.
- Masukkan server sebagai localhost.
- Masukkan nama situs sebagai Situs Web / Demo Default.
- Letakkan url tujuan sebagai http://localhost/Demo
Kemudian klik tombol Next.
Step 16 - Di layar berikutnya, klik Berikutnya.
Step 17 - Di layar terakhir yang muncul, klik tombol Publikasikan.
Sekarang jika Anda pergi ke C:\Demo\Simple\Properties\PublishProfiles lokasi proyek Anda, Anda akan melihat yang baru publish profile xml filedibuat. File profil terbitkan ini akan memiliki semua detail yang diperlukan untuk menerbitkan aplikasi Anda ke server IIS lokal.
Step 18- Sekarang mari kita sesuaikan perintah MSBuild kita dan gunakan profil terbitkan di atas dan lihat apa yang terjadi. Dalam perintah MSBuild kami, kami menentukan parameter berikut -
Deploy on Build benar - ini akan memicu penerapan otomatis setelah build yang berhasil selesai.
Kami kemudian menyebutkan untuk menggunakan profil Publikasikan yang digunakan pada langkah di atas.
Versi Visual Studio hanya untuk disebutkan ke kapabilitas penyebaran MSBuild pada versi apa dari Visual Studio yang digunakan.
Saat Anda menjalankan perintah di atas, MSBuild akan memicu proses pembuatan dan penerapan. Apa yang akan Anda catat, itu menerapkannya ke kamiDefault Website di Server IIS kami.
Sekarang jika kita menelusuri situs - http://localhost/Demo/Demo.aspx kita akan melihat keluaran berikut, yang berarti bahwa MSBuild berhasil menyebarkan ke situs web kita.
Step 19 - Mengotomatiskan melalui TeamCity - Sekarang saatnya menambahkan tugas ke server TeamCity kami untuk secara otomatis menggunakan MSBuild untuk menyebarkan aplikasi kami, berdasarkan langkah-langkah yang disebutkan di atas.
Step 20 - Buka dasbor proyek Anda dan klik Edit Configuration Settings.
Step 21 - Pergi ke Build Steps dan klik Add a Build step.
Pilih opsi berikut -
Jenis pelari harus MSBuild
Berikan nama Langkah opsional
Masukkan jalur build sebagai Simple / Simple.csproj
Pertahankan versi MSBuild sebagai Microsoft Build Tools 2013
Pertahankan versi Alat MSBuild sebagai 12.0
Letakkan baris perintah sebagai / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0
Step 22 - Klik Simpan.
Pastikan bahwa dalam langkah-langkah pembuatan, langkah Penerapan adalah langkah terakhir dalam rangkaian.
Step 23 - Sekarang mari kita lakukan final git commit, untuk memastikan semua file ada di Git dan dapat digunakan oleh TeamCity.
Selamat, Anda telah berhasil menyiapkan Siklus Integrasi Berkelanjutan lengkap untuk aplikasi Anda, yang dapat dijalankan kapan saja.
Mari kita tinjau ulang praktik terbaik Integrasi Berkelanjutan berdasarkan semua pelajaran yang telah kita pelajari sejauh ini -
Maintain a code repository- Ini adalah langkah paling dasar. Dalam semua contoh kami, semuanya disimpan dalam repositori Git langsung dari basis kode hingga profil Publikasikan, hingga skrip basis data. Harus selalu dipastikan bahwa semuanya disimpan dalam repositori kode.
Automate the build- Kami telah melihat cara menggunakan MSBuild untuk mengotomatiskan build bersama dengan menggunakan profil publikasikan. Ini sekali lagi merupakan langkah kunci dalam proses Integrasi berkelanjutan.
Make the build self-testing - Pastikan Anda dapat menguji build dengan menyimpan kasus pengujian unit dan kasus pengujian ini harus sedemikian rupa sehingga dapat dijalankan oleh server Integrasi Berkelanjutan.
Everyone commits to the baseline every day- Ini adalah prinsip utama Integrasi Berkelanjutan. Tidak ada gunanya tinggal sampai akhir seluruh proses untuk melihat siapa yang merusak build.
Every commit (to baseline) should be built- Setiap komit yang dibuat untuk aplikasi, harus berhasil dibangun. Jika build gagal karena alasan apa pun, kode perlu diubah untuk memastikan build berhasil.
Keep the build fast- Jika buildnya lambat, itu akan menunjukkan masalah di seluruh proses Continuous Integration. Pastikan build selalu dibatasi pada durasi, sebaiknya tidak melebihi 10 menit.
Everyone can see the results of the latest build- Dasbor TeamCity memberi semua orang pandangan tentang semua build, yang telah lulus atau gagal. Ini memberikan wawasan yang baik kepada semua orang yang terlibat dalam proses Integrasi Berkelanjutan.