Hari dalam kehidupan pengembang devops: Menulis kode baru untuk cerita pengguna

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Tutorial ini menjelaskan bagaimana Anda dan tim Anda bisa mendapatkan manfaat maksimum dari versi terbaru Team Foundation Version Control (TFVC) dan Visual Studio untuk membangun aplikasi Anda. Tutorial ini memberikan contoh bagaimana Anda dapat menggunakan Visual Studio dan TFVC untuk memeriksa dan memperbarui kode, menangguhkan pekerjaan saat Anda terganggu, meminta peninjauan kode, memeriksa perubahan Anda, dan melakukan tugas lain.

Ketika tim mengadopsi Visual Studio dan TFVC untuk mengelola kode mereka, mereka menyiapkan server dan komputer klien mereka, membuat backlog, merencanakan perulangan, dan menyelesaikan perencanaan lain yang diperlukan untuk mulai mengembangkan aplikasi mereka.

Pengembang meninjau backlog mereka untuk memilih tugas yang akan dikerjakan. Mereka menulis pengujian unit untuk kode yang mereka rencanakan untuk dikembangkan. Biasanya, mereka menjalankan tes beberapa kali dalam satu jam, secara bertahap menulis tes yang lebih rinci dan kemudian menulis kode yang membuatnya lulus. Pengembang sering mendiskusikan antarmuka kode mereka dengan kolega yang akan menggunakan metode yang mereka tulis.

Alat Visual Studio My Work and Code Review membantu pengembang mengelola pekerjaan mereka dan berkolaborasi dengan kolega.

Catatan

Fitur Visual Studio My Work and Code Review tersedia dengan edisi berikut:

• Visual Studio 2022: Komunitas Visual Studio, Visual Studio Professional, dan Visual Studio Enterprise
• Visual Studio 2019: Visual Studio Professional dan Visual Studio Enterprise

Tinjau item kerja dan bersiaplah untuk mulai bekerja

Tim telah menyetujui bahwa, selama sprint saat ini, Anda akan mengerjakan Evaluasi status faktur, item prioritas utama di backlog produk. Anda memutuskan untuk memulai dengan Menerapkan fungsi matematika, tugas anak dari item backlog prioritas teratas.

Di Visual Studio Team Explorer, pada halaman Kerja Saya, Anda menyeret tugas ini dari daftar Item Kerja yang Tersedia ke dalam daftar Sedang Berlangsung.

Untuk meninjau backlog Anda dan menyiapkan tugas untuk mulai bekerja

1. Di Team Explorer, jika Anda belum tersambung ke proyek yang ingin Anda kerjakan, sambungkan ke proyek.

2. Dari halaman Beranda , pilih Pekerjaan Saya.

3. Pada halaman Kerja Saya, seret tugas dari daftar Item Kerja yang Tersedia ke bagian Sedang Berlangsung Kerja .

   Anda juga bisa memilih tugas di daftar Item Kerja yang Tersedia lalu pilih Mulai.

Rencana kerja inkremental draf

Anda mengembangkan kode dalam serangkaian langkah kecil. Setiap langkah biasanya memakan waktu tidak lebih dari satu jam, dan mungkin memakan waktu sesedikit 10 menit. Dalam setiap langkah, Anda menulis pengujian unit baru dan mengubah kode yang Anda kembangkan sehingga lulus pengujian baru, selain pengujian yang telah Anda tulis. Terkadang Anda menulis pengujian baru sebelum mengubah kode, dan terkadang Anda mengubah kode sebelum menulis pengujian. Kadang-kadang Anda refaktor. Artinya, Anda hanya meningkatkan kode tanpa menambahkan pengujian baru. Anda tidak pernah mengubah pengujian yang lolos, kecuali Anda memutuskan bahwa pengujian tersebut tidak mewakili persyaratan dengan benar.

Di akhir setiap langkah kecil, Anda menjalankan semua pengujian unit yang relevan dengan area kode ini. Anda tidak mempertimbangkan langkah selesai sampai setiap pengujian lulus.

Anda tidak memeriksa kode ke Azure DevOps Server hingga Anda menyelesaikan seluruh tugas.

Anda dapat menuliskan rencana kasar untuk urutan langkah-langkah kecil ini. Anda tahu bahwa detail dan urutan yang tepat dari yang nanti mungkin akan berubah saat Anda bekerja. Berikut adalah daftar awal langkah-langkah untuk tugas khusus ini:

1. Buat metode pengujian stub-yaitu, hanya tanda tangan metode .
2. Memuaskan satu kasus khas tertentu.
3. Uji rentang yang luas. Pastikan kode merespons dengan benar ke berbagai nilai.
4. Pengecualian pada negatif. Berurusan dengan baik dengan parameter yang salah.
5. Cakupan kode. Pastikan bahwa setidaknya 80% kode dijalankan oleh pengujian unit.

Beberapa pengembang menulis rencana semacam ini dalam komentar dalam kode pengujian mereka. Yang lain hanya menghafal rencana mereka. Ini bisa berguna untuk menulis daftar langkah-langkah Anda di bidang Deskripsi item kerja Tugas. Jika Anda harus beralih sementara ke tugas yang lebih mendesak, Anda tahu di mana menemukan daftar saat Anda dapat kembali ke tugas tersebut.

Membuat pengujian unit pertama

Mulailah dengan membuat pengujian unit. Mulailah dengan pengujian unit karena Anda ingin menulis contoh kode yang menggunakan kelas baru Anda.

Ini adalah pengujian unit pertama untuk pustaka kelas yang Anda uji, sehingga Anda membuat proyek pengujian unit baru.

1. Pilih File>Proyek Baru.
2. Dalam kotak dialog Buat proyek baru, pilih panah di samping Semua bahasa dan pilih C#, pilih panah di samping Semua jenis proyek dan pilih Uji, lalu pilih MSTest Test Project.
3. Pilih Berikutnya, lalu pilih Buat.

Di editor kode, ganti konten UnitTest1.cs dengan kode berikut. Pada tahap ini, Anda hanya ingin menggambarkan bagaimana salah satu metode baru Anda akan dipanggil:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Anda menulis contoh dalam metode pengujian karena, pada saat Anda menulis kode, Anda ingin contoh berfungsi.

Untuk membuat proyek dan metode pengujian unit

Biasanya Anda membuat proyek pengujian baru untuk setiap proyek yang sedang diuji. Jika proyek pengujian sudah ada, Anda cukup menambahkan metode dan kelas pengujian baru.

Tutorial ini menggunakan Visual Studio Unit Test Framework, tetapi Anda juga dapat menggunakan kerangka kerja dari penyedia lain. Test Explorer bekerja sama baiknya dengan kerangka kerja lain, asalkan Anda menginstal adaptor yang sesuai.

1. Buat proyek Uji dengan menggunakan langkah-langkah sebelumnya. Anda dapat memilih bahasa seperti C#, F#, dan Visual Basic.

2. Tambahkan pengujian Anda ke kelas pengujian yang disediakan. Setiap pengujian unit adalah satu metode.

   • Setiap pengujian unit harus diawali oleh TestMethod atribut , dan metode pengujian unit tidak boleh memiliki parameter. Anda dapat menggunakan nama apa pun yang Anda inginkan untuk metode pengujian unit:

     [TestMethod]
     public void SignatureTest()
     {...}
     

     <TestMethod()>
     Public Sub SignatureTest()
     ...
     End Sub
     

   • Setiap metode pengujian harus memanggil metode Assert kelas, untuk menunjukkan apakah itu telah lulus atau gagal. Biasanya, Anda memverifikasi bahwa hasil operasi yang diharapkan dan aktual sama:

     Assert.AreEqual(expectedResult, actualResult);
     

     Assert.AreEqual(expectedResult, actualResult)
     

   • Metode pengujian Anda dapat memanggil metode biasa lain yang tidak memiliki TestMethod atribut .

   • Anda dapat mengatur pengujian Anda ke dalam lebih dari satu kelas. Setiap kelas harus diawali oleh TestClass atribut .

     [TestClass]
     public class UnitTest1
     { ... }
     

     <TestClass()>
     Public Class UnitTest1
     ...
     End Class
     

Untuk informasi tentang cara menulis pengujian unit di C++, lihat Menulis pengujian Unit untuk C/C++ dengan Microsoft Unit Testing Framework untuk C++.

Membuat stub untuk kode baru

Selanjutnya, buat proyek pustaka kelas untuk kode baru Anda. Sekarang ada proyek untuk kode yang sedang dikembangkan dan proyek untuk pengujian unit. Tambahkan referensi proyek dari proyek pengujian ke kode yang sedang dikembangkan.

Dalam proyek baru, Anda menambahkan kelas baru dan versi minimal metode yang setidaknya akan memungkinkan pengujian berhasil dibangun. Cara tercepat untuk melakukan itu adalah dengan menghasilkan kelas dan stub metode dari pemanggilan dalam pengujian.

public double SquareRoot(double p)
{
    throw new NotImplementedException();
}

Untuk menghasilkan kelas dan metode dari pengujian

Pertama, buat proyek tempat Anda ingin menambahkan kelas baru, kecuali sudah ada.

Untuk menghasilkan kelas

1. Tempatkan kursor pada contoh kelas yang ingin Anda hasilkan, misalnya, LocalMath, dan pilih Tindakan Cepat dan Pemfaktoran Ulang.
2. Pada menu pintasan, pilih Hasilkan jenis baru.
3. Dalam kotak dialog Buat Jenis , atur Proyek ke proyek pustaka kelas. Dalam contoh ini, ini adalah Fabrikam.Math.

Untuk menghasilkan metode

1. Tempatkan kursor pada panggilan ke metode , misalnya, SquareRoot, dan pilih Tindakan Cepat dan Pemfaktoran Ulang.
2. Pada menu pintasan, pilih Buat metode 'SquareRoot'.

Jalankan pengujian pertama

Buat dan jalankan pengujian. Hasil pengujian menunjukkan indikator Gagal merah dan pengujian muncul di bawah daftar Pengujian Gagal.

Buat perubahan sederhana pada kode:

public double SquareRoot(double p)
{
    return 0.0;
}

Jalankan pengujian lagi dan lulus.

Untuk menjalankan pengujian unit

Untuk menjalankan pengujian unit:

• Pilih Uji>Jalankan Semua Pengujian
• Atau, jika Test Explorer terbuka, pilih Jalankan atau Jalankan Semua Pengujian Dalam Tampilan.

Jika pengujian muncul di bawah Pengujian Gagal, buka pengujian, misalnya, dengan mengklik dua kali nama. Titik di mana pengujian gagal ditampilkan di editor kode.

• Untuk melihat daftar lengkap pengujian, pilih Tampilkan Semua.

• Untuk melihat detail hasil pengujian, pilih pengujian di Test Explorer.

• Untuk menavigasi ke kode pengujian, klik dua kali pengujian di Test Explorer, atau pilih Buka Uji pada menu pintasan.

• Untuk men-debug pengujian, buka menu pintasan untuk satu atau beberapa pengujian, lalu pilih Debug.

• Untuk menjalankan pengujian di latar belakang setiap kali Anda membangun solusi, pilih panah di samping ikon Pengaturan, lalu pilih Jalankan Pengujian Setelah Build. Pengujian yang sebelumnya gagal dijalankan terlebih dahulu.

Setujui antarmuka

Anda dapat berkolaborasi dengan kolega yang akan menggunakan komponen Anda dengan berbagi layar. Kolega mungkin berkomentar bahwa banyak fungsi akan lulus tes sebelumnya. Jelaskan bahwa pengujian ini hanya untuk memastikan bahwa nama dan parameter fungsi sudah benar, dan sekarang Anda dapat menulis pengujian yang menangkap persyaratan utama fungsi ini.

Anda berkolaborasi dengan kolega untuk menulis tes berikut:

[TestMethod]
public void QuickNonZero()
{
    // Create an instance to test:
    LocalMath math = new LocalMath();

    // Create a test input and expected value:
    var expectedResult = 4.0;
    var inputValue = expectedResult * expectedResult;

    // Run the method:
    var actualResult = math.SquareRoot(inputValue);

    // Validate the result:
    var allowableError = expectedResult/1e6;
    Assert.AreEqual(expectedResult, actualResult, allowableError,
        "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
}

Tip

Untuk fungsi ini, Anda menggunakan pengembangan pertama pengujian, di mana Anda pertama kali menulis pengujian unit untuk fitur, lalu menulis kode yang memenuhi pengujian. Dalam kasus lain, praktik ini tidak realistis, jadi Anda menulis tes setelah Anda menulis kode. Tetapi sangat penting untuk menulis pengujian unit, baik sebelum atau sesudah kode, karena mereka menjaga kode tetap stabil.

Merah, Hijau, Refaktor...

Ikuti siklus di mana Anda berulang kali menulis pengujian dan mengonfirmasi bahwa itu gagal, menulis kode untuk membuat lulus pengujian, dan kemudian mempertimbangkan pemfaktoran ulang, yaitu meningkatkan kode tanpa mengubah pengujian.

Merah

Jalankan semua pengujian, termasuk pengujian baru yang Anda buat. Setelah Anda menulis pengujian apa pun, selalu jalankan untuk memastikan bahwa pengujian gagal sebelum Anda menulis kode yang membuatnya lulus. Misalnya, jika Anda lupa menempatkan pernyataan dalam beberapa pengujian yang Anda tulis, melihat hasil Fail memberi Anda keyakinan bahwa ketika Anda berhasil lulus, hasil pengujian dengan benar menunjukkan bahwa persyaratan telah terpenuhi.

Praktik lain yang berguna adalah mengatur Jalankan Pengujian Setelah Build. Opsi ini menjalankan pengujian di latar belakang setiap kali Anda membangun solusi, sehingga Anda memiliki laporan berkelanjutan tentang status pengujian kode Anda. Anda mungkin khawatir bahwa praktik ini mungkin membuat Visual Studio lambat merespons, tetapi ini jarang terjadi.

Hijau

Menulis upaya pertama Anda pada kode metode yang Sedang Anda kembangkan:

public class LocalMath
{
    public double SquareRoot(double x)
    {
        double estimate = x;
        double previousEstimate = -x;
        while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
        {
            previousEstimate = estimate;
            estimate = (estimate * estimate - x) / (2 * estimate);
        }
        return estimate;
    }

Jalankan pengujian lagi, dan semua tes lulus.

Menentukan faktor kembali

Sekarang setelah kode melakukan fungsi utamanya, lihat kode untuk menemukan cara membuatnya berkinerja lebih baik, atau untuk membuatnya lebih mudah diubah di masa depan. Anda dapat mengurangi jumlah perhitungan yang dilakukan dalam perulangan:

public class LocalMath
{
    public double SquareRoot(double x)
    {
        double estimate = x;
        double previousEstimate = -x;
        while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
        {
            previousEstimate = estimate; 
            estimate = (estimate + x / estimate) / 2;
            //was: estimate = (estimate * estimate - x) / (2 * estimate);
        }
        return estimate;
    }

Verifikasi bahwa pengujian masih lulus.

Tips

• Setiap perubahan yang Anda buat saat mengembangkan kode harus berupa pemfaktoran ulang atau ekstensi:

  • Pemfaktoran ulang berarti Anda tidak mengubah pengujian karena Anda tidak menambahkan fungsionalitas baru.
  • Ekstensi berarti menambahkan pengujian dan membuat perubahan kode yang diperlukan untuk lulus pengujian yang sudah ada dan baru.

• Jika Anda memperbarui kode yang ada ke persyaratan yang telah berubah, Anda juga menghapus pengujian lama yang tidak lagi mewakili persyaratan saat ini.

• Hindari mengubah pengujian yang telah lulus. Sebagai gantinya, tambahkan pengujian baru. Hanya tulis tes yang mewakili persyaratan nyata.

• Jalankan pengujian setelah setiap perubahan.

... dan ulangi

Lanjutkan serangkaian langkah ekstensi dan refaktor Anda, menggunakan daftar langkah-langkah kecil Anda sebagai panduan kasar. Anda tidak selalu melakukan langkah pemfaktoran ulang setelah setiap ekstensi, dan terkadang Anda melakukan lebih dari satu langkah pemfaktoran ulang secara berturut-turut. Tetapi Anda selalu menjalankan pengujian unit setelah setiap perubahan pada kode.

Terkadang Anda menambahkan pengujian yang tidak memerlukan perubahan pada kode, tetapi itu menambah keyakinan Anda bahwa kode berfungsi dengan benar. Misalnya, Anda ingin memastikan bahwa fungsi berfungsi di berbagai input. Anda menulis lebih banyak tes, seperti ini:

[TestMethod]
public void SqRtValueRange()
{
    LocalMath math = new LocalMath();
    for (double expectedResult = 1e-8;
        expectedResult < 1e+8;
        expectedResult = expectedResult * 3.2)
    {
        VerifyOneRootValue(math, expectedResult);
    }
}
private void VerifyOneRootValue(LocalMath math, double expectedResult)
{
    double input = expectedResult * expectedResult;
    double actualResult = math.SquareRoot(input);
    Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
}

Tes ini lulus saat pertama kali dijalankan.

Hanya untuk memastikan hasil ini bukan kesalahan, Anda dapat memperkenalkan kesalahan kecil untuk sementara ke dalam pengujian Anda untuk membuatnya gagal. Setelah melihat kegagalan, Anda dapat memperbaikinya lagi.

Tip

Selalu buat pengujian gagal sebelum Anda berhasil lulus.

Pengecualian

Sekarang lanjutkan ke menulis tes untuk input luar biasa:

[TestMethod]
public void RootTestNegativeInput()
{
    LocalMath math = new LocalMath();
    try
    {
        math.SquareRoot(-10.0);
    }
    catch (ArgumentOutOfRangeException)
    {
        return;
    }
    catch
    {
        Assert.Fail("Wrong exception on negative input");
        return;
    }
    Assert.Fail("No exception on negative input");
}

Tes ini menempatkan kode ke dalam perulangan. Anda harus menggunakan tombol Batal di Test Explorer. Ini mengakhiri kode dalam waktu 10 detik.

Anda ingin memastikan bahwa perulangan tanpa akhir tidak dapat terjadi di server build. Meskipun server memberlakukan batas waktu pada eksekusi lengkap, ini adalah batas waktu yang sangat lama, dan akan menyebabkan penundaan yang substansial. Oleh karena itu, Anda dapat menambahkan batas waktu eksplisit ke pengujian ini:

[TestMethod, Timeout(1000)]
public void RootTestNegativeInput()
{...

Batas waktu eksplisit membuat pengujian gagal.

Perbarui kode untuk menangani kasus luar biasa ini:

public double SquareRoot(double x)
{
    if (x <= 0.0) 
    {
        throw new ArgumentOutOfRangeException();
    }

Regresi

Tes baru lolos, tapi ada regresi. Tes yang digunakan untuk lulus sekarang gagal:

Temukan dan perbaiki kesalahan:

public double SquareRoot(double x)
{
    if (x < 0.0)  // not <=
    {
        throw new ArgumentOutOfRangeException();
    }

Setelah diperbaiki, semua tes lulus:

Tip

Pastikan setiap pengujian lulus setelah setiap perubahan yang Anda buat pada kode.

Cakupan kode

Pada interval selama pekerjaan Anda, dan akhirnya sebelum Anda memeriksa kode, dapatkan laporan cakupan kode. Ini menunjukkan berapa banyak kode yang telah dilakukan oleh pengujian Anda.

Tim Anda bertujuan untuk cakupan setidaknya 80%. Mereka melonggarkan persyaratan ini untuk kode yang dihasilkan, karena mungkin sulit untuk mencapai cakupan tinggi untuk jenis kode ini.

Cakupan yang baik bukanlah jaminan bahwa fungsionalitas lengkap komponen telah diuji, dan tidak menjamin bahwa kode akan berfungsi untuk setiap rentang nilai input. Namun demikian, ada korelasi yang cukup dekat antara cakupan baris kode dan cakupan ruang perilaku komponen. Oleh karena itu, cakupan yang baik memperkuat keyakinan tim bahwa mereka menguji sebagian besar perilaku yang seharusnya.

Untuk mendapatkan laporan cakupan kode, di menu Uji Visual Studio, pilih Analisis Cakupan Kode untuk Semua Pengujian. Semua pengujian berjalan lagi.

Saat Anda memperluas total dalam laporan, itu menunjukkan bahwa kode yang Anda kembangkan memiliki cakupan lengkap. Ini sangat memuaskan, karena skor penting adalah untuk kode yang sedang diuji. Bagian yang belum ditemukan sebenarnya ada dalam tes itu sendiri.

Dengan mengalihkan tombol Tampilkan Pewarnaan Cakupan Kode, Anda dapat melihat bagian mana dari kode pengujian yang belum dijalankan. Kode yang tidak digunakan dalam pengujian disorot dengan warna oranye. Namun, bagian ini tidak penting untuk cakupan karena berada dalam kode pengujian dan akan digunakan hanya jika kesalahan terdeteksi.

Untuk memverifikasi bahwa pengujian tertentu mencapai cabang kode tertentu, Anda dapat mengatur Tampilkan Pewarnaan Cakupan Kode lalu menjalankan satu pengujian dengan menggunakan perintah Jalankan pada menu pintasannya.

Kapan kau selesai?

Anda terus memperbarui kode dalam langkah-langkah kecil sampai Anda puas bahwa:

• Semua pengujian unit yang tersedia lulus.

  Dalam proyek dengan serangkaian pengujian unit yang sangat besar, mungkin tidak praktis bagi pengembang untuk menunggu mereka semua berjalan. Sebagai gantinya, proyek ini mengoperasikan layanan check-in terjaga, di mana semua pengujian otomatis dijalankan untuk setiap shelveset yang diperiksa sebelum digabungkan ke pohon sumber. Check-in ditolak jika eksekusi gagal. Hal ini memungkinkan pengembang untuk menjalankan serangkaian pengujian unit minimal pada komputer mereka sendiri, dan kemudian melanjutkan dengan pekerjaan lain, tanpa menjalankan risiko merusak build. Untuk informasi selengkapnya, lihat Menggunakan proses build check-in yang terjaga untuk memvalidasi perubahan.

• Cakupan kode memenuhi standar tim. 75% adalah persyaratan proyek yang khas.

• Pengujian unit Anda mensimulasikan setiap aspek perilaku yang diperlukan, termasuk input khas dan luar biasa.

• Kode Anda mudah dipahami dan diperluas.

Ketika semua kriteria ini terpenuhi, Anda siap untuk memeriksa kode Anda ke kontrol sumber.

Prinsip pengembangan kode dengan pengujian unit

Terapkan prinsip-prinsip berikut saat mengembangkan kode:

• Kembangkan pengujian unit bersama dengan kode, dan sering jalankan selama pengembangan. Pengujian unit mewakili spesifikasi komponen Anda.
• Jangan ubah pengujian unit, kecuali persyaratan telah berubah atau pengujian salah. Tambahkan pengujian baru secara bertahap saat Anda memperluas fungsionalitas kode.
• Bidik setidaknya 75% kode Anda untuk dicakup oleh pengujian. Lihat hasil cakupan kode pada interval, dan sebelum Anda memeriksa kode sumber.
• Periksa pengujian unit Anda bersama dengan kode, sehingga akan dijalankan oleh build server berkelanjutan atau reguler.
• Jika praktis, untuk setiap fungsionalitas, tulis pengujian unit terlebih dahulu. Lakukan ini sebelum Anda mengembangkan kode yang memenuhinya.

Periksa perubahan

Sebelum memeriksa perubahan, sekali lagi bagikan layar Anda dengan kolega sehingga mereka dapat meninjau secara informal dan interaktif dengan Anda apa yang telah Anda buat. Tes terus menjadi fokus diskusi Anda dengan kolega yang terutama tertarik pada apa yang dilakukan kode, bukan cara kerjanya. Rekan-rekan ini harus setuju bahwa apa yang telah Anda tulis memenuhi kebutuhan mereka.

Periksa semua perubahan yang telah Anda buat, termasuk pengujian dan kode, dan kaitkan dengan tugas yang telah Anda selesaikan. Check-in mengantrekan sistem build tim otomatis tim untuk memvalidasi perubahan Anda menggunakan proses build CI Build tim. Proses build ini membantu tim meminimalkan kesalahan dalam basis kode mereka dengan membangun dan menguji, di lingkungan yang bersih terpisah dari komputer pengembangan mereka, setiap perubahan yang dilakukan tim.

Anda akan diberi tahu saat build selesai. Di jendela hasil build, Anda melihat bahwa build berhasil dan semua pengujian lulus.

Untuk memeriksa perubahan

1. Pada halaman Pekerjaan Saya di Team Explorer, pilih Check in.

   

2. Pada halaman Perubahan Tertunda , pastikan bahwa:

   • Semua perubahan yang relevan tercantum dalam Perubahan yang Disertakan.
   • Semua item kerja yang relevan tercantum dalam Item Kerja Terkait.

3. Masukkan Komentar untuk membantu tim Anda memahami tujuan perubahan ini saat melihat riwayat kontrol versi file dan folder yang diubah.

4. Pilih Check In.

   

Untuk terus mengintegrasikan kode

Untuk informasi selengkapnya tentang cara menentukan proses build integrasi berkelanjutan, lihat Menyiapkan build CI. Setelah menyiapkan proses build ini, Anda dapat memilih untuk diberi tahu tentang hasil build tim.

Untuk informasi selengkapnya, lihat Menjalankan, memantau, dan mengelola build.

Langkah berikutnya

Menangguhkan pekerjaan, memperbaiki bug, dan melakukan peninjauan kode