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 Kontrola wersji serwera Team Foundation (TFVC) i 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 and 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 przebiegu będziesz pracować nad pozycją Ocena stanu faktury, elementem najwyższego priorytetu na liście prac produktu. Decydujesz się rozpocząć od implementowania funkcji matematycznych, podrzędnego zadania elementu listy prac o najwyższym priorytcie.

W programie Visual Studio Team Explorer na stronie Moja praca przeciągniesz to zadanie z listy Dostępne elementy robocze do listy Praca w toku .

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

1. Jeśli w programie Team Explorer nie masz jeszcze połączenia z projektem, w którym chcesz pracować, połącz się z projektem.

2. Na stronie głównej wybierz pozycję Moja praca.

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

   Możesz również wybrać zadanie z listy Dostępne elementy robocze, a 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 zmienisz testu, który przebiegnie, chyba że zdecydujesz, że nie jest on poprawnie reprezentowany przez wymaganie.

Na końcu każdego małego kroku uruchamiasz wszystkie testy jednostkowe, które są istotne dla tego obszaru kodu. Nie należy traktować tego kroku do momentu ukończenia każdego testu.

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ść nowszych prawdopodobnie zmienią się podczas pracy. Oto początkowa lista kroków dla tego konkretnego zadania:

1. Utwórz metodę testową , czyli tylko sygnaturę metody.
2. Spełnij jeden konkretny typowy przypadek.
3. Testowanie szerokiego zakresu. Upewnij się, że kod prawidłowo odpowiada na duży zakres wartości.
4. Wyjątek dla wartości ujemnej. Zająć się bezpiecznie nieprawidłowymi parametrami.
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 testowej biblioteki klas, dzięki czemu utworzysz nowy projekt testu jednostkowego.

1. Wybierz pozycję Plik>nowy projekt.
2. W oknie dialogowym Tworzenie nowego projektu wybierz strzałkę obok pozycji Wszystkie języki i wybierz pozycję C#, wybierz strzałkę obok pozycji Wszystkie typy projektów i wybierz pozycję Test, a następnie wybierz pozycję Projekt testowy MSTest.
3. Wybierz Dalej, a następnie wybierz 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 można napisać w metodzie testowej, ponieważ w czasie pisania kodu chcesz pracować w przykładzie.

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 strukturami, pod warunkiem zainstalowania odpowiedniej karty.

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ć żadnych 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ę Assert klasy, 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 na temat 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++.

Tworzenie wycinku dla nowego kodu

Następnie utwórz projekt biblioteki klas dla nowego kodu. Istnieje teraz projekt dla kodu opracowywanego i projektu 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, i wybierz pozycję Szybkie akcje i refaktoryzacje.
2. W menu skrótów wybierz pozycję Generuj nowy typ.
3. W oknie dialogowym Generowanie typu ustaw wartość 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, i wybierz pozycję Szybkie akcje i refaktoryzacje.
2. W menu skrótów wybierz pozycję Generuj metodę "SquareRoot".

Uruchamianie pierwszego testu

Skompiluj i uruchom test. Wynik testu przedstawia czerwony wskaźnik Niepowodzenie , a test jest wyświetlany na liście testów niepowodzeniem.

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ę Testuj>uruchom wszystkie testy
• Ewentualnie, jeśli eksplorator testów jest otwarty, wybierz pozycję 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 pozycję Pokaż wszystko.

• 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 polecenie Otwórz test w menu skrótów.

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

• Aby uruchamiać 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);
}

Napiwek

W przypadku tej funkcji należy najpierw użyć programowania testowego, 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, dlatego 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, Refaktoryzacja...

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 kończy się niepowodzeniem przed napisanie kodu, który go przekazuje. Jeśli na przykład zapomnisz umieścić asercji w niektórych testach, które piszesz, zobaczysz wynik Niepowodzenie daje pewność, że po zakończeniu testu wynik testu prawidłowo wskazuje, że wymaganie zostało spełnione.

Innym przydatnym rozwiązaniem jest ustawienie uruchamiania testów po kompilacji. 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.

Green (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 przebiegnie po raz pierwszy.

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 wystąpieniu błędu można go naprawić ponownie.

Napiwek

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.

Chcesz upewnić się, że na serwerze kompilacji nie może wystąpić nieskończona pętla. Mimo że serwer nakłada limit czasu na pełny przebieg, jest to bardzo długi limit czasu i spowodowałoby 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 używany do przejścia 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:

Napiwek

Upewnij się, że wszystkie testy są wykonywane po każdej zmianie wykonywanej w kodzie.

Pokrycie kodu

W odstępach czasu podczas pracy, a na koniec przed zaewidencjoniem kodu uzyskaj raport pokrycia kodu. Pokazuje to, ile kodu zostało wykonane przez testy.

Twój zespół ma na celu pokrycie 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 zwiększa pewność zespołu, że testuje większość zachowań, które powinny.

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 sumy w raporcie zostanie wyświetlony kod, który tworzysz, ma pełne pokrycie. Jest to bardzo zadowalające, ponieważ ważny wynik jest dla kodu testowego. Odkryte sekcje są rzeczywiście w samych testach.

Przełączając przycisk Pokaż kolorowanie pokrycia kodu, możesz zobaczyć, które części kodu testowego nie zostały wykonane. 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ć opcję Pokaż kolorowanie pokrycia kodu, a następnie uruchomić pojedynczy test przy użyciu polecenia Uruchom w menu skrótów.

Kiedy skończysz?

Kod można zaktualizować w małych krokach, dopóki nie zostanie spełnione następujące warunki:

• 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. Zaewidencjonuj zostanie odrzucona, jeśli przebieg zakończy się niepowodzeniem. 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 Use a gated check-in build process to validate changes (Używanie procesu kompilacji zaewidencjonowanej bramki do weryfikowania zmian).

• 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 sprawdzić kod w kontroli źródła.

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ę składnika.
• 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.
• Staraj się, aby co najmniej 75% kodu było objętych testami. Przed zaewidencjonuj wyniki pokrycia kodu w interwałach i przed zaewidencjonuj kod źródłowy.
• 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.

Zaewidencjonuj zmiany

Przed zaewidencjonowanie zmian ponownie udostępnij ekran współpracownikom, aby mogli nieformalnie i interaktywnie przeglądać zawartość utworzonego przez Ciebie. Testy nadal skupiają się na dyskusjach ze współpracownikami, którzy są przede wszystkim zainteresowani tym, co robi kod, a nie jego działaniem. 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 zespołu w celu zweryfikowania zmian przy użyciu procesu kompilacji ciągłej integracji 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 zaewidencjonować zmiany

1. Na stronie Moja praca w programie Team Explorer wybierz pozycję Zaewidencjonuj.

   

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

   • Wszystkie istotne zmiany są wymienione w uwzględnionych zmianach.
   • Wszystkie odpowiednie elementy robocze są wymienione w powiązanych elementach roboczych.

3. Wprowadź komentarz, aby ułatwić zespołowi zrozumienie przeznaczenia tych zmian podczas analizowania historii kontroli wersji zmienionych plików i folderów.

4. Wybierz pozycję Synchronizacja.

   

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 kompilacji i zarządzanie nimi.

Następne kroki

Zawieszanie pracy, naprawianie usterki i przeprowadzanie przeglądu kodu