Dzień w życiu dewelopera devops: pisanie nowego kodu dla historii użytkownika

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

W tym samouczku opisano, jak ty i Twój zespół mogą uzyskać maksymalną korzyść z najnowszych wersji kontroli wersji programu Team Foundation (TFVC) i programu Visual Studio w celu skompilowania aplikacji. Samouczek zawiera przykłady użycia programów Visual Studio i TFVC w celu wyewidencjonowania i aktualizowania kodu, wstrzymania pracy po przerwaniu, zażądaniu przeglądu kodu, zaewidencjonowania zmian i wykonywania innych zadań.

Gdy zespół wdraża programy Visual Studio i TFVC do zarządzania kodem, konfigurują swój serwer i maszyny klienckie, tworzą listę prac, planują iterację i wykonują inne planowanie niezbędne do rozpoczęcia tworzenia aplikacji.

Deweloperzy przeglądają swoje listy prac, aby wybrać zadania do pracy. Piszą testy jednostkowe dla kodu, który planuje opracować. Zazwyczaj uruchamiają testy kilka razy w ciągu godziny, stopniowo zapisują bardziej szczegółowe testy, a następnie piszą kod, który sprawia, że przechodzą. Deweloperzy często omawiają interfejsy kodu współpracownikom, którzy będą używać metody, którą piszą.

Narzędzia visual Studio My Work i Code Review ułatwiają deweloperom zarządzanie pracą i współpracę z innymi osobami.

Uwaga

Funkcje przeglądu mojego pracy i kodu w programie Visual Studio są dostępne w następujących wersjach:

• Visual Studio 2022: Visual Studio Community, Visual Studio Professional i Visual Studio Enterprise
• Visual Studio 2019: Visual Studio Professional i Visual Studio Enterprise

Przeglądanie elementów roboczych i przygotowywanie do rozpoczęcia pracy

Zespół zgodził się, że podczas bieżącego sprintu będziesz pracować nad Ocena stanu faktury, element najwyższego priorytetu w rejestrze produktu. Postanawiasz rozpocząć od Implementowanie funkcji matematycznych, podrzędne zadanie elementu listy prac o najwyższym priorytcie.

W programie Visual Studio Team Explorerna stronie Moja Praca przeciągnij to zadanie z listy Dostępnych Elementów Roboczych do listy Praca w Toku.

Aby przejrzeć listę prac i przygotować zadania do rozpoczęcia pracy

1. W programie Team Explorer, jeśli nie masz jeszcze połączenia z projektem, w którym chcesz pracować, nawiąż połączenie z projektem, w którym chcesz pracować.

2. Na stronie głównej wybierz opcję My Work.

3. Na stronie My Work przeciągnij zadanie z listy Dostępne elementy robocze do sekcji Praca w toku.

   Możesz również wybrać zadanie na liście "Dostępne elementy robocze" i następnie wybrać pozycję "Uruchom".

Wersja robocza planu pracy przyrostowego

Kod jest opracowywany w serii małych kroków. Każdy krok zwykle trwa nie dłużej niż godzinę i może potrwać nawet 10 minut. W każdym kroku napiszesz nowy test jednostkowy i zmienisz opracowywany kod, tak aby przeszedł nowy test, oprócz już napisanych testów. Czasami piszesz nowy test przed zmianą kodu, a czasami zmieniasz kod przed napisaniem testu. Czasami refaktoryzujesz. Oznacza to, że wystarczy poprawić kod bez dodawania nowych testów. Nigdy nie zmieniasz testu, który przeszedł, chyba że zdecydujesz, że nie odpowiada on poprawnie wymogowi.

Na końcu każdego małego kroku uruchamiasz wszystkie testy jednostkowe, które są istotne dla tego obszaru kodu. Nie uznajesz kroku za ukończony, dopóki wszystkie testy nie zostaną zaliczone.

Nie zaewidencjonujesz kodu na serwerze Azure DevOps Server, dopóki nie zakończysz całego zadania.

Możesz zapisać przybliżony plan dla tej sekwencji małych kroków. Wiesz, że dokładne szczegóły i kolejność tych późniejszych zapewne się zmienią, jak będziesz pracować. Oto początkowa lista kroków dla tego konkretnego zadania:

1. Utwórz stub metody testowej, czyli tylko sygnaturę metody.
2. Spełnij jeden konkretny typowy przypadek.
3. Testuj szeroki zakres. Upewnij się, że kod prawidłowo odpowiada na duży zakres wartości.
4. Wyjątek dla wartości ujemnej. Umiejętnie obsłużyć nieprawidłowe parametry.
5. Pokrycie kodu. Upewnij się, że co najmniej 80% kodu% jest wykonywane przez testy jednostkowe.

Niektórzy deweloperzy piszą ten rodzaj planu w komentarzach w kodzie testowym. Inni po prostu zapamiętują swój plan. Może być przydatne napisanie listy kroków w polu Opis elementu roboczego Zadanie. Jeśli musisz tymczasowo przełączyć się do bardziej pilnego zadania, wiesz, gdzie znaleźć listę, gdy możesz do niej wrócić.

Tworzenie pierwszego testu jednostkowego

Rozpocznij od utworzenia testu jednostkowego. Zacznij od testu jednostkowego, ponieważ chcesz napisać przykład kodu, który używa nowej klasy.

Jest to pierwszy test jednostkowy dla biblioteki klas, która jest testowana, więc utworzysz nowy projekt testu jednostkowego.

1. Wybierz Plik>Nowy projekt.
2. W oknie dialogowym Tworzenie nowego projektu wybierz strzałkę obok pozycji Wszystkie języki i wybierz język C#, wybierz strzałkę obok Wszystkie typy projektów i wybierz Test, a następnie wybierz MSTest Test Project.
3. Wybierz pozycję Dalej, a następnie wybierz pozycję Utwórz.

W edytorze kodu zastąp zawartość UnitTest1.cs następującym kodem. Na tym etapie po prostu chcesz zilustrować, jak zostanie wywołana jedna z nowych metod:

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);
        }
    }
}

Przykład piszesz w metodzie testowej, ponieważ gdy piszesz swój kod, chcesz, aby przykład działał poprawnie.

Aby utworzyć projekt i metody testów jednostkowych

Zazwyczaj tworzony jest nowy projekt testowy dla każdego testowanego projektu. Jeśli projekt testowy już istnieje, możesz po prostu dodać nowe metody i klasy testowe.

W tym samouczku jest używana struktura Visual Studio Unit Test Framework, ale możesz również używać struktur od innych dostawców. Eksplorator testów działa równie dobrze z innymi frameworkami, pod warunkiem zainstalowania odpowiedniego adaptera.

1. Utwórz projekt testowy przy użyciu powyższych kroków. Możesz wybrać języki, takie jak C#, F#i Visual Basic.

2. Dodaj testy do udostępnionej klasy testowej. Każdy test jednostkowy jest jedną metodą.

   • Każdy test jednostkowy musi być poprzedzony atrybutem TestMethod, a metoda testu jednostkowego nie powinna mieć parametrów. Możesz użyć dowolnej nazwy dla metody testu jednostkowego:

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

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

   • Każda metoda testowa powinna wywołać metodę klasy Assert, aby wskazać, czy zakończyła się powodzeniem, czy niepowodzeniem. Zazwyczaj sprawdza się, czy oczekiwane i rzeczywiste wyniki operacji są równe:

     Assert.AreEqual(expectedResult, actualResult);
     

     Assert.AreEqual(expectedResult, actualResult)
     

   • Metody testowe mogą wywoływać inne zwykłe metody, które nie mają atrybutu TestMethod.

   • Testy można organizować w więcej niż jedną klasę. Każda klasa musi być poprzedzona atrybutem TestClass.

     [TestClass]
     public class UnitTest1
     { ... }
     

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

Aby uzyskać informacje o sposobie pisania testów jednostkowych w języku C++, zobacz Pisanie testów jednostkowych dla języka C/C++ przy użyciu platformy Microsoft Unit Testing Framework dla języka C++.

Stwórz szkielet dla nowego kodu

Następnie utwórz projekt biblioteki klas dla nowego kodu. Istnieje teraz projekt dla opracowywanego kodu i projekt dla testów jednostkowych. Dodaj odwołanie do projektu testowego do kodu opracowywanego.

W nowym projekcie dodasz nową klasę i minimalną wersję metody, która pozwoli na pomyślną kompilację testu. Najszybszym sposobem, aby to zrobić, jest wygenerowanie klasy i wycinku metody z wywołania w teście.

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

Generowanie klas i metod na podstawie testów

Najpierw utwórz projekt, w którym chcesz dodać nową klasę, chyba że już istnieje.

Aby wygenerować klasę

1. Umieść kursor na przykładzie klasy, którą chcesz wygenerować, na przykład LocalMath, a następnie wybierz pozycję Szybkie akcje i refaktoryzacje.
2. W menu skrótów wybierz pozycję Wygeneruj nowy typ.
3. W oknie dialogowym Generowanie typu , ustaw Project na projekt biblioteki klas. W tym przykładzie jest to Fabrikam.Math.

Aby wygenerować metodę

1. Umieść kursor na wywołaniu metody, na przykład SquareRoot, a następnie wybierz Szybkie działania i refaktoryzacje.
2. W menu skrótów wybierz pozycję Generuj metodę 'SquareRoot'.

Uruchamianie pierwszego testu

Skompiluj i uruchom test. Wynik testu pokazuje czerwony wskaźnik Niepowodzenie, a test jest wyświetlany na liście Niepowodzeń Testów.

Wprowadź prostą zmianę w kodzie:

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

Uruchom ponownie test i przebiegnie pomyślnie.

Aby uruchomić testy jednostkowe

Aby uruchomić testy jednostkowe:

• Wybierz pozycję Test>Uruchom wszystkie testy
• Jeśli Eksplorator testów jest otwarty, wybierz Uruchom lub Uruchom wszystkie testy w widoku.

Jeśli test pojawi się w obszarze Testy nieudane, otwórz test, na przykład, klikając dwukrotnie nazwę. Punkt, w którym test zakończył się niepowodzeniem, jest wyświetlany w edytorze kodu.

• Aby wyświetlić pełną listę testów, wybierz Pokaż wszystkie.

• Aby wyświetlić szczegóły wyniku testu, wybierz test w eksploratorze testów .

• Aby przejść do kodu testu, kliknij dwukrotnie test w eksploratorze testów, lub wybierz Otwórz test w menu kontekstowym.

• Aby debugować test, otwórz menu skrótów dla co najmniej jednego testu, a następnie wybierz pozycję Debuguj.

• Aby uruchomić testy w tle za każdym razem, gdy kompilujesz rozwiązanie, wybierz strzałkę obok ikony Ustawienia, a następnie wybierz pozycję Uruchom testy po kompilacji. Najpierw są uruchamiane testy, które wcześniej zakończyły się niepowodzeniem.

Uzgadnianie interfejsu

Możesz współpracować ze współpracownikami, którzy będą używać składnika, udostępniając ekran. Współpracownik może skomentować, że wiele funkcji przejdzie poprzedni test. Wyjaśnij, że ten test polegał tylko na upewnieniu się, że nazwa i parametry funkcji są poprawne, a teraz możesz napisać test, który przechwytuje główne wymaganie tej funkcji.

Współpracujesz z innymi osobami, aby napisać następujący test:

[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);
}

Wskazówka

W przypadku tej funkcji należy użyć test pierwszego programowania, w którym najpierw napiszesz test jednostkowy dla funkcji, a następnie napiszesz kod, który spełnia test. W innych przypadkach ta praktyka nie jest realistyczna, więc musisz pisać testy po napisaniu kodu. Jednak bardzo ważne jest, aby pisać testy jednostkowe, zarówno przed, jak i po kodzie, ponieważ zachowują one stabilność kodu.

Czerwony, Zielony, Refactor...

Postępuj zgodnie z cyklem, w którym wielokrotnie piszesz test i potwierdzasz, że kończy się niepowodzeniem, napisz kod, aby wykonać test, a następnie rozważ refaktoryzację, która poprawia kod bez zmieniania testów.

Czerwony

Uruchom wszystkie testy, w tym nowy utworzony test. Po zapisaniu dowolnego testu zawsze uruchom go, aby upewnić się, że zawodzi przed napisaniem kodu, który sprawia, że przechodzi. Jeśli na przykład zapomnisz dodać asercji do niektórych testów, które piszesz, zobaczenie wyniku Niepowodzenie daje ci pewność, że gdy naprawisz test tak, aby przeszedł, wynik będzie prawidłowo wskazywał, że wymaganie zostało spełnione.

Innym przydatnym rozwiązaniem jest ustawienie uruchomienie testów pokompilacji. Ta opcja uruchamia testy w tle za każdym razem, gdy kompilujesz rozwiązanie, dzięki czemu masz ciągły raport stanu testu kodu. Być może obawiasz się, że ta praktyka może spowolnić odpowiedź programu Visual Studio, ale rzadko się tak dzieje.

Zielony

Zapisuje pierwszą próbę kodu opracowywanej metody:

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;
    }

Uruchom ponownie testy, a wszystkie testy kończą się powodzeniem.

Refaktoryzacja

Teraz, gdy kod wykonuje swoją główną funkcję, przyjrzyj się kodowi, aby znaleźć sposoby na lepsze działanie lub ułatwić zmianę w przyszłości. Liczbę obliczeń wykonywanych w pętli można zmniejszyć:

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;
    }

Sprawdź, czy testy nadal przechodzą pomyślnie.

Wskazówki

• Każda zmiana wprowadzana podczas opracowywania kodu powinna być refaktoryzowaniem lub rozszerzeniem:

  • Refaktoryzacja oznacza, że nie zmieniasz testów, ponieważ nie dodajesz nowych funkcji.
  • Rozszerzenie oznacza dodawanie testów i wprowadzanie zmian w kodzie, które są niezbędne do przejścia zarówno istniejących, jak i nowych testów.

• Jeśli aktualizujesz istniejący kod do wymagań, które uległy zmianie, usuwasz również stare testy, które nie reprezentują już bieżących wymagań.

• Unikaj zmieniania testów, które już przeszły. Zamiast tego dodaj nowe testy. Zapisuj tylko testy reprezentujące rzeczywiste wymaganie.

• Uruchom testy po każdej zmianie.

... i powtórz

Kontynuuj serię kroków rozszerzenia i refaktoryzacji, korzystając z listy małych kroków jako przybliżonego przewodnika. Nie zawsze wykonujesz krok refaktoryzacji po każdym rozszerzeniu, a czasami wykonujesz więcej niż jeden krok refaktoryzacji z rzędu. Jednak zawsze uruchamiasz testy jednostkowe po każdej zmianie kodu.

Czasami dodasz test, który nie wymaga zmiany w kodzie, ale zwiększa pewność, że kod działa poprawnie. Na przykład chcesz upewnić się, że funkcja działa w szerokim zakresie danych wejściowych. Piszesz więcej testów, takich jak ten:

[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);
}

Ten test przechodzi pomyślnie za pierwszym razem, gdy jest uruchamiany.

Aby upewnić się, że ten wynik nie jest błędem, możesz tymczasowo wprowadzić mały błąd do testu, aby go zakończyć niepowodzeniem. Po zauważeniu usterki można ją naprawić ponownie.

Wskazówka

Przed ukończeniem testu należy zawsze wykonać test.

Wyjątki

Teraz przejdź do pisania testów dla wyjątkowych danych wejściowych:

[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");
}

Ten test umieszcza kod w pętli. Musisz użyć przycisku Anuluj w eksploratorze testów . Spowoduje to zakończenie kodu w ciągu 10 sekund.

Musisz się upewnić, że na serwerze kompilacji nie może wystąpić nieskończona pętla. Mimo że serwer nakłada limit czasu na pełne działanie, limit jest bardzo długi i powoduje znaczne opóźnienie. W związku z tym można dodać jawny limit czasu do tego testu:

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

Jawny limit czasu sprawia, że test zakończy się niepowodzeniem.

Zaktualizuj kod, aby poradzić sobie z tym wyjątkowym przypadkiem:

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

Regresja

Nowy test zakończy się pomyślnie, ale występuje regresja. Test, który kiedyś przechodził, teraz kończy się niepowodzeniem.

Znajdź i napraw błąd:

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

Po jego naprawieniu wszystkie testy kończą się powodzeniem:

Wskazówka

Upewnij się, że wszystkie testy przechodzą po każdej modyfikacji kodu.

Pokrycie kodu

W regularnych odstępach czasu podczas pracy, a na koniec przed zaewidencjonowaniem kodu, uzyskaj raport dotyczący pokrycia kodu. Pokazuje to, ile kodu zostało przetestowane przez twoje testy.

Twój zespół dąży do osiągnięcia zasięgu co najmniej 80%. Zrelaksują to wymaganie dotyczące wygenerowanego kodu, ponieważ osiągnięcie wysokiego pokrycia tego typu kodu może być trudne.

Dobre pokrycie nie jest gwarancją, że pełna funkcjonalność składnika została przetestowana i nie gwarantuje, że kod będzie działał dla każdego zakresu wartości wejściowych. Niemniej jednak istnieje dość bliska korelacja między pokryciem wierszy kodu i pokryciem przestrzeni behawioralnej składnika. W związku z tym dobre pokrycie wzmacnia zaufanie zespołu, że testują większość zachowań, które powinny testować.

Aby uzyskać raport pokrycia kodu, w menu test programu Visual Studio wybierz pozycję Analizuj pokrycie kodu dla wszystkich testów. Wszystkie testy są uruchamiane ponownie.

Po rozwinięciu całkowitej sumy w raporcie widać, że kod, który tworzysz, ma pełne pokrycie. Jest to bardzo zadowalające, ponieważ istotny wynik dotyczy testowanego kodu. Sekcje ujawnione rzeczywiście istnieją w samych testach.

Przełączając przycisk Pokaż kolorowanie pokrycia kodu, możesz zobaczyć, które części kodu testowego nie zostały przetestowane. Kod, który nie został użyty w testach, jest wyróżniony kolorem pomarańczowym. Jednak te sekcje są nieistotne dla pokrycia, ponieważ znajdują się w kodzie testowym i będą używane tylko wtedy, gdy zostanie wykryty błąd.

Aby sprawdzić, czy określony test dociera do określonych gałęzi kodu, możesz ustawić Pokaż kolorowanie pokrycia kodu, a następnie uruchomić pojedynczy test przy użyciu polecenia Uruchom w menu skrótów.

Kiedy skończysz?

Nadal aktualizujesz kod małymi krokami, dopóki nie jesteś zadowolony z tego, że:

• Wszystkie dostępne testy jednostkowe przechodzą pomyślnie.

  W projekcie z bardzo dużym zestawem testów jednostkowych może być niepraktyczne, aby deweloper czekał na ich uruchomienie. Zamiast tego projekt obsługuje bramkową usługę ewidencjonowania, w której wszystkie testy automatyczne są uruchamiane dla każdego zestawu na półce zaewidencjonowanej przed scaleniem z drzewem źródłowym. Zaewidencjonowanie zostanie odrzucone, jeśli przebieg nie powiedzie się. Dzięki temu deweloperzy mogą uruchamiać minimalny zestaw testów jednostkowych na własnych maszynach, a następnie kontynuować inną pracę bez ryzyka przerwania kompilacji. Aby uzyskać więcej informacji, zobacz Użyj procesu tworzenia z weryfikacją dla wprowadzania zmian, aby je zatwierdzać.

• Pokrycie kodu spełnia standardy zespołu. 75% jest typowym wymaganiem projektu.

• Testy jednostkowe symulują każdy aspekt wymaganego zachowania, w tym typowe i wyjątkowe dane wejściowe.

• Kod jest łatwy do zrozumienia i rozszerzenia.

Po spełnieniu wszystkich tych kryteriów możesz wprowadzić swój kod do systemu kontroli wersji.

Zasady tworzenia kodu przy użyciu testów jednostkowych

Zastosuj następujące zasady podczas tworzenia kodu:

• Twórz testy jednostkowe wraz z kodem i uruchamiaj je często podczas programowania. Testy jednostkowe reprezentują specyfikację komponentu.
• Nie zmieniaj testów jednostkowych, chyba że wymagania uległy zmianie lub testy były błędne. Stopniowo dodawaj nowe testy w miarę rozszerzania funkcjonalności kodu.
• Celem co najmniej 75% kodu, które mają być objęte testami. Sprawdzaj wyniki pokrycia kodu w regularnych odstępach czasu oraz przed przekazaniem kodu źródłowego.
• Zaewidencjonuj testy jednostkowe wraz z kodem, aby były uruchamiane przez ciągłe lub regularne kompilacje serwera.
• Jeśli jest to praktyczne, dla każdego elementu funkcjonalności najpierw napisz test jednostkowy. Zrób to przed opracowaniem kodu, który go spełnia.

Prześlij zmiany

Przed zaewidencjonowaniem zmian ponownie udostępnij ekran współpracownikom, aby mogli nieformalnie i interaktywnie przeanalizować to, co stworzyłeś/stworzyłaś. Testy nadal są głównym tematem dyskusji ze współpracownikami, którzy są przede wszystkim zainteresowani tym, co robi kod, a nie tym, jak działa. Ci współpracownicy powinni zgodzić się, że to, co napisałeś, spełnia ich potrzeby.

Zaewidencjonuj wszystkie wprowadzone zmiany, w tym testy i kod, i skojarz je z ukończonymi zadaniami. Ewidencjonowanie kolejkuje zautomatyzowany system kompilacji zespołu w celu zweryfikowania zmian przy użyciu procesu budowy CI Build zespołu. Ten proces kompilacji pomaga zespołowi zminimalizować błędy w bazie kodu, tworząc i testując, w czystym środowisku niezależnie od komputerów programistycznych, każda zmiana wprowadzana przez zespół.

Otrzymasz powiadomienie po zakończeniu kompilacji. W oknie wyników kompilacji zobaczysz, że kompilacja zakończyła się pomyślnie i wszystkie testy zakończyły się pomyślnie.

Aby zatwierdzić zmiany

1. Na stronie Moja Praca w Team Explorerwybierz Zaewidencjonuj.

   

2. Na stronie Oczekujące zmiany upewnij się, że:

   • Wszystkie istotne zmiany są wymienione w Uwzględnione Zmiany.
   • Wszystkie odpowiednie elementy robocze są wymienione w powiązane elementy robocze.

3. Dodaj komentarz , aby pomóc zespołowi zrozumieć cel tych zmian podczas przeglądania historii wersji zmienionych plików i folderów.

4. Wybierz pozycję zaewidencjonuj.

   

Aby stale integrować kod

Aby uzyskać więcej informacji na temat definiowania procesu kompilacji ciągłej integracji, zobacz Konfigurowanie kompilacji ciągłej integracji. Po skonfigurowaniu tego procesu kompilacji możesz otrzymywać powiadomienia o wynikach kompilacji zespołu.

Aby uzyskać więcej informacji, zobacz Uruchamianie, monitorowanie i zarządzanie kompilacjami.

Następne kroki

wstrzymać pracę, naprawić usterkę i przeprowadzić przegląd kodu