Dzień pracy dewelopera Informatykami: wpisać nowy kod dla wątku użytkownika

Jesteś nowy użytkownik programu Visual Studio aplikacji cyklu zarządzania (ALM) i Team Foundation Server (TFS)?Czy możesz zastanawiasz się, jak zespół można uzyskać maksymalną korzystać z najnowszej wersji tych narzędzi do tworzenia aplikacji użytkownika?

Następnie potrwać kilka minut i walk krok po kroku przez ten samouczek rozdział dwóch dnia życia Piotra i Julia dwóch programistów na włókno Fabrikam — fikcyjnej firmy, telewizji kablowej i powiązanych usług.Zobaczysz przykłady jak wyewidencjonować i zaktualizować kod, zawieszenia pracy podczas pracy przerwane, wniosek o dokonanie przeglądu kodu, zaewidencjonować zmiany i wykonywać inne zadania można użyć programu Visual Studio i TFS.

Dotychczas wątku

Zespół niedawno rozpoczął przyjmujące Visual Studio i Team Foundation Server dla aplikacji cyklu zarządzania (ALM).Ich ustawić serwer i komputerów klienckich, zaległości, utworzone planowane iteracji i zakończone innych planowania niezbędne do rozpoczęcia rozwijania ich aplikacji.

Omówienie tego rozdziału.

Peter krótko jego zaległości recenzje i wybiera zadanie, które on będzie działać na dzisiaj.Pisze testów jednostki dla kodu, który zamierza rozwijać.Zwykle prowadzi badania w godziny, pisania stopniowo bardziej szczegółowe badania i następnie pisania kodu, który czyni je przekazywać.Omówiono on często interfejsu jego kod ze współpracownikami, używający metody, którą on jest w formie pisemnej.

[!UWAGA]

Moja praca i Code Coverage funkcje, które zostały omówione w tym temacie są dostępne tylko w Visual Studio Premium i Visual Studio Ultimate.

W tym temacie

• Przejrzyj osobiste zaległości i przygotowania do rozpoczęcia pracy zadań

• Tworzenie pierwszego badania jednostki

• Tworzenie skrótowej dla nowego kodu

• Uruchom test pierwszy

• Postanawiają API

• Red, Green, byłaby...

• Użycie kodu

• Kiedy są możemy zrobić?

• Zaewidencjonuj zmiany

Przejrzyj osobiste zaległości i przygotowania do rozpoczęcia pracy zadań

W Explorer zespołu, Peter otwiera Moja praca strony.Zespół uzgodniła, że podczas bieżącego sprint, Peter będzie działać na stan faktury Szacuj, element góry priorytet w zaległości produktu.Peter zdecyduje się zaczynać wykonują funkcje matematyczne, zadania podrzędne elementu zaległości góry priorytet.On przeciągnie tego zadania z Dostępne elementy robocze listę do elementów pracy w toku & Zmiany listy.

Przejrzyj osobiste zaległości i przygotowania do rozpoczęcia pracy zadań

1. W Explorer zespołu:

   1. Jeśli połączenie nie jest już do zespołu projektu, do którego chcesz pracować, następnie połączenia z projektem zespołu.

   2. Choose Home, and then choose My Work.

2. Na Moja praca strony, należy przeciągnąć zadanie z Dostępne elementy robocze listę do Elementów pracy w toku sekcji.

   Można również wybrać zadania w Dostępne elementy robocze listy, a następnie wybierz polecenie Start.

Projekt planu pracy w przyrostowe

Peter rozwija zazwyczaj kod serii małych kroków.Każdy krok zazwyczaj trwa nie dłużej niż godzinę i może potrwać nawet dziesięć minut.W każdym kroku on kod, który rozwija się on tak, aby przeszła nowego testu, oprócz badań, który był już zapisane zmiany i zapisuje nowy test jednostki.Czasami pisze nowy test przed zmianą kodu i czasem zmienia kod przed zapisaniem badania.Czasami on refactors.Oznacza to, że on po prostu zwiększa kod bez dodawania nowych badań.Test, który przekazuje, on nigdy nie zmienia chyba że zdecydował, że go nie poprawnie stanowiły zapotrzebowania.

Na końcu każdego kroku małych uruchamia on wszystkie testy jednostki, które są istotne dla tego obszaru kodu.Nie uzna krok pełną do każdego testu.

Jednakże on nie będzie sprawdzać kod do Team Foundation Server aż zakończy on całego zadania.

Peter zapisuje w dół surowca plan dla tej sekwencji małych kroków.Wie, że dokładne szczegóły i kolejność później te prawdopodobnie zmieni jak on działa.Oto jego wstępny wykaz kroki dla tego zadania:

1. Tworzenie skrótowej metody badania — czyli tylko sygnatura metody.

2. Spełniają szczególne jeden typowy przypadek.

3. Test szerokiego zakresu.Upewnij się, że kod poprawnie odpowiada na duży zakres wartości.

4. Wyjątek na negatywną.Łagodnie zajmuje niepoprawne parametry.

5. Kod zapotrzebowania.Upewnij się, że co najmniej 80% kodu jest wykonywane przez jednostki badań.

Niektóre z jego współpracownicy Napisz tego rodzaju planu komentarzy w ich kodu testu.Inne tylko zapamiętywać ich planu.Peter znajdzie przydatne do zapisu jego listy kroków w polu Opis elementu pracy zadania.Jeśli miał powinny tymczasowo przełączyć się do bardziej pilne zadania, wie gdzie znaleźć listy, gdy jest w stanie zwrócić.

Tworzenie pierwszego badania jednostki

Peter zaczyna się od utworzenia test jednostki.Rozpoczyna test jednostki, ponieważ chce napisać przykładowy kod, który używa jego nowej klasy.

To pierwszy test jednostki dla biblioteki klas, że jest on testowanie, więc tworzy nowy projekt badania jednostki.Otwiera on Nowy projekt okno dialogowe i wybierze Visual C#, Test, a następnie Projektu badania jednostki.

Projekt badania jednostki udostępnia pliku C# do którego on zapisu jego przykład.Na tym etapie po prostu chce ilustrują, jak jeden z jego nowej metody wywoływane:

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

Pisze przykład w metodzie badania, ponieważ do czasu, który napisał jego kod chce przykład do pracy.

Aby utworzyć jednostkę badania projektu i metod

Zazwyczaj należy utworzyć nowy projekt badania dla każdego projektu, który jest badany.Jeśli projekt badania już istnieje, wystarczy dodać nowych metod badań i klas.

Ta procedura używa struktury testowej jednostki Visual Studio, ale umożliwia także RAM od innych dostawców.Test Explorer works równie dobrze z innych systemów, pod warunkiem zainstalowania odpowiednie karty.

• Tworzenie projektu badania, jeśli jeszcze nie istnieje.

  • W Nowy projekt okno dialogowe Wybierz język, takich jak programu Visual Basic, Visual C++ lub Visual C#.Wybierz Test a projektu badania jednostki.

• Testy należy dodać do klasy testowej, dostarczonego.Badanie każdej jednostki jest jedną z metod.

  Każdy test jednostki muszą być poprzedzane TestMethod atrybutu i metody badania jednostki powinny mieć żadnych parametrów.Można użyć dowolnego nazwę metody badania jednostki:

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

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

• Każda metoda badania należy wywołać metodę Assert klasy, aby wskazać, czy został przekazany lub nie powiodło się.Zazwyczaj można sprawdzić, czy rzeczywistych i oczekiwanych wyników operacji są równe:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Twoje metody badania może wywołać innych zwykłych metod, które nie mają TestMethod atrybut.

• Testy można organizować w więcej niż jednej klasy.Każda klasa muszą być poprzedzane TestClass atrybut.

  [TestClass]
  public class UnitTest1
  { ... }
  

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

Aby uzyskać więcej informacji na temat pisania w języku C++ testy zobacz Zapisywanie jednostki badań dla C/C++ z ramami badania jednostki firmy Microsoft dla języka C++.

Tworzenie skrótowej dla nowego kodu

Dalej Peter tworzy projekt biblioteki klas dla jego nowy kod.Obecnie istnieje projektu dla kodu w rozwoju i projektów badań jednostki.Dodaje odwołanie projektu z projektu badania kodu w rozwoju.

W nowym projekcie dodaje nowe klasy i minimalna wersja metodę, która pozwoli przynajmniej test do konstruowania pomyślnie.Najszybszym sposobem na to jest do generowania skrótowej klasy i metody z wywołania w badaniu.

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

Aby wygenerować klasy i metody badań

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

Aby wygenerować klasy

1. Umieść kursor na przykład klasy chcesz wygenerować, na przykład LocalMath.W menu skrótów wybierz polecenie Generowania kodu, Nowy typ.

2. W Nowy typ okno dialogowe, set projektu do projektu biblioteki klas.W tym przykładzie jest Fabrikam.Math.

Aby wygenerować metody

• Umieść kursor na wywołanie metody, na przykład SquareRoot.W menu skrótów wybierz polecenie Generowania kodu, Skrótowych metoda.

Uruchom test pierwszy

Peter tworzy i uruchamia test, naciskając klawisze CTRL + R, T.Wynik badania wskazuje czerwony wskaźnik nie powiodło się i badania pojawia się w obszarze listy Failed testów.

Tworzy proste zmiany kodu:

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

Prowadzi badania i przekazuje go:

Aby uruchomić testy

• Na Test menu wybierz uruchomić, Wszystkie testy.

  - lub -

• Test Explorer jest otwarty, wybierz polecenie Uruchomić wszystkie.

  - lub -

• Umieść kursor w pliku kodu testu i naciśnij klawisz CTRL + R, T.

• Jeśli test, który pojawia się pod Failed testów:

  Otwórz badania, na przykład przez dwukrotne kliknięcie nazwy.

  Punkt, w którym jest wyświetlany niepomyślnie.

Aby wyświetlić pełną listę testów, wybierz Pokaż wszystkie.Aby powrócić do podsumowania, wybierz domu widok.

Aby wyświetlić szczegóły dotyczące wyników badania wybierz test w Eksploratorze badania.

Przejdź do kodu testu, kliknij dwukrotnie test w Eksploratorze badania lub wybierz Otwórz Test w menu skrótów.

Debugowanie badania, otworzyć menu skrótów dla jednej lub więcej prób, a następnie wybierz Debugowania wybrane testy.

Aby uruchomić testy w tle, ilekroć zbudować roztwór, Przełącz Uruchomić testy po kompilacji.Testy, które wcześniej nie są uruchamiane w pierwszym.

Postanawiają interfejsu

Peter wzywa jego kolega Julia Lync i udziałów jego ekranu.Będzie ona używając jego części.Pokazuje on jego przykład początkowego.

Julia zdaniem przykład jest OK, ale komentarze "wiele funkcji miało przejść test".

Peter odpowiedzi "pierwszy test jest właśnie po to, aby upewnić się, że nazwa i parametry funkcji są poprawne.Teraz możemy napisać test, który przechwytuje główny warunek tej funkcji."

Razem napisać następujące badania:

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

Porada
Dla tej funkcji Peter używa Test pierwszego rozwoju, w którym on najpierw zapisuje test jednostki dla funkcji, a następnie zapisuje kod, który spełnia badania.W innych przypadkach stwierdza ona, że praktyka ta nie jest realny, więc natomiast pisze testy po pisze kod.Ale uzna to za bardzo ważne, aby pisać testy — przed lub po kodzie — ponieważ kod prowadzą stabilne.

Red, Green, byłaby...

Peter następuje cykl, w którym wielokrotnie zapisuje test i potwierdza nie powiedzie się, zapisuje kod, aby badania przekazać, i uważa, przeróbek — czyli poprawy kodu bez zmiany testy.

Czerwony

Peter naciśnie klawisze CTRL + R, T, aby uruchomić nowy test został utworzony z Julia.Po pisze każde badanie on zawsze uruchamia go, aby upewnić się, że nie przed pisze kod, który umożliwia przekazywanie.Jest to praktyka, który dowiedział się po zapomniał on miejsce w niektórych testów, w którym miał on potwierdzeń.Wyświetlanie wyników Fail daje mu pewności, że ułatwia on przekazać, wynik badania poprawnie oznacza wymóg został spełniony.

Inną praktyką użyteczne jest Uruchomić testy po kompilacji.Ta opcja uruchamia testy w tle przy każdym zbudować roztwór, tak, aby raport stałego badania stanu kodu.Peter został najpierw podejrzanych, że może mieć Visual Studio wolno reagować, ale stwierdzi, że rzadko dzieje.

Zielony

Peter zapisuje jego pierwsza próba kod metody, który rozwija się on:

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

Peter ponownie uruchamia testy i przekazać wszystkie testy:

Refactor

Teraz, że kod wykonuje swoje główne funkcje, Peter przegląda kod znaleźć sposoby, dzięki czemu lepiej lub ułatwić zmianie w przyszłości.Realizuje on on zmniejsza liczbę obliczenia wykonywane w pętli:

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

Weryfikuje, testy wciąż przekazać:

Porada

Każdej zmiany wprowadzone podczas opracowywania kodu należy przeróbek lub rozszerzenie: Przeróbek środki, aby nie zmieniać badania, ponieważ nie dodajesz nowych funkcji. Rozszerzenie oznacza dodawanie badań i dokonywania zmiany kodu, które są niezbędne do przekazywania zarówno istniejące, jak i nowych badań. Aktualizowania istniejącego kodu do wymogów, które uległy zmianie, spowoduje również usunięcie starych testów, które nie reprezentują bieżące wymagania. Należy unikać zmieniania testów, które zostały już przekazane.Zamiast tego można dodawać nowych badań.Zapisywać tylko testy, które reprezentują rzeczywiste wymagania. Uruchom testy po każdej zmianie.

... i powtórz

Peter nadal jego serii rozszerzenia i przeróbek kroki, jako wskazówka przy użyciu jego listy małych kroków.On nie zawsze wykonać krok przeróbek po każdego rozszerzenia, a czasami wykonuje więcej niż jednego etapu przeróbek kolejno.Ale on zawsze uruchamia testy jednostki po każdej zmianie kodu.

Czasami dodaje on badania, to nie wymaga żadnych zmian w kodzie, ale dodaje jego pewności, że jego kod działa poprawnie.Na przykład chce upewnić się, że funkcja pracuje nad szeroki zakres wejść.Pisze więcej badań, taką jak poniżej:

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

Prawdziwe podczas pierwszego uruchomienia:

Tylko, aby upewnić się, że wynik ten nie jest błędem, on tymczasowo wprowadza niewielkie błędy do próby stał się nie powieść.Po awarii, jego rozwiązanie go ponownie.

Porada
Należy zawsze test awarii przed wprowadzeniem go przekazać.

Wyjątki

Peter teraz przechodzi do pisania testów wyjątkowych środków produkcji:

[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.Ma używać anulowanie przycisk Test Explorer.Kod ten kończy się w ciągu 10 sekund.

Peter chce, aby upewnić się, że w pętli nieskończonej nie może się zdarzyć na serwerze kompilacji.Chociaż serwer nakłada limit czasu na zakończenie uruchomić, jest bardzo długi czas oczekiwania i mogłoby spowodować znaczne opóźnienia.Dlatego dodaje on jawne limit czasu tego testu:

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

Limit czasu jawne sprawia, że test awarii.

Peter następnie aktualizuje kod przeciwdziałania tym wyjątkowym przypadku:

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

Regresji

Nowe badania przebiegi, ale istnieje regresji.Test, który jest używany do przekazywania ulegnie awarii:

Peter znajduje i naprawia błąd:

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

Po jest ustalona, należy przekazać wszystkie testy:

Porada
Upewnij się, co przebiegów testów po każdej zmianie na kod.

Użycie kodu

W odstępach czasu podczas swojej pracy i wreszcie przed sprawdza on w kodzie, Peter uzyskuje raportu kod zapotrzebowania.Pokazuje to, wiele kod ma wykonane przez jego badania.

Zespół Piotra celem dla pokrycia co najmniej 80%.One złagodzenie tego wymogu w przypadku wygenerowany kod, ponieważ może być trudne do osiągnięcia wysokiego zapotrzebowania dla tego typu kodu.

Dobre pokrycie nie gwarantują, że funkcjonalność składnik został przetestowany i nie gwarantuje, że kod będzie działać dla każdego zakresu wartości wejściowych.Niemniej jednak jest dość ścisłej korelacji między zapotrzebowania wiersze kodu i pokrycia behawioralnej miejsca składnika.Dlatego dobre pokrycie wzmacnia zespołowi pewności, że testowania większość zachowanie, które powinny.

Uzyskać raport kod zapotrzebowania na testów menu wybierz uruchomić, Analizować kod zapotrzebowania dla wszystkich testów.Następnie uruchom ponownie wszystkie testy.

Peter pobiera całkowitą zapotrzebowania 86%.Rozszerza on sumy w raporcie, pokazuje, że kod, który rozwija się on ma zasięg 100%.Jest to bardzo zadowalające, ponieważ jest ocena ważnych dla badanego kodu.Sekcje niepokrytych są faktycznie samych testów.Przełączając Pokaż kolorowanie pokrycia kodu przycisk Peter można zobaczyć części kodu badania, które mają nie wykonywane.Jednak zdecydował się sekcje te są nieistotnych dla pokrycia, ponieważ są w kodzie testu i będzie używane, jeśli zostanie wykryty błąd.

Aby zweryfikować, że szczególne badania osiągnie do określonych gałęzi kodu, można ustawić Pokaż kolorowanie pokrycia kodu , a następnie uruchomić pojedynczego badania za pomocą uruchomić polecenia menu skrótów.

Kiedy są możemy zrobić?

Peter nadal należy zaktualizować kod w małych kroków, dopóki jest przekonany, że:

• Dostępne jednostki badań przebiegu.

  W programie project dużego zestawu testów może być niepraktyczne dla deweloperów oczekiwania je wszystkie do uruchomienia.Zamiast tego projektu działa gated w wyboru usługi, w którym wszystkie testy automatyczne są uruchamiane dla każdego sprawdzane shelveset przed scalania w drzewie źródła.Wyboru w jest odrzucona, jeśli uruchamianie nie powiedzie się.Dzięki temu deweloper Uruchom minimalny zestaw testów na własnym komputerze i następnie kontynuować bez ryzyka rozdzielenie budowanie innych prac.Aby uzyskać więcej informacji, zobacz Zdefiniowanie procesu Gated kompilacji wyboru, aby zatwierdzić zmiany.

• Użycie kodu spełnia normy zespołu.75% jest wymóg typowy projekt.

• Jego testy symulacji każdego aspektu zachowanie, włączając zarówno typowe i wyjątkowych nakłady wymagane.

• Jego kod jest łatwe do zrozumienia i rozszerzenie.

Gdy te kryteria są spełnione, Peter jest gotowy do sprawdzenia jego kod w formancie źródła.

Zasady rozwoju kodu z jednostki badań

Peter stosuje się następujące zasady przy opracowywaniu kodu:

• Opracowanie jednostki badań wraz z kodem i uruchom je często w trakcie rozwoju.Badania jednostki reprezentują specyfikacja składnika.

• Nie należy zmieniać jednostki badań, chyba że zostały zmienione wymogi lub testy były niewłaściwe.Dodać nowe badania stopniowo rozszerzać funkcjonalność kodu.

• Co najmniej 75% kodu celu objęte badań.Obejrzyj wyniki kod zapotrzebowania odstępach i przed rozpoczęciem sprawdzania kodu źródłowego.

• Zaewidencjonowanie testy jednostki z kodu, tak, że będą one wykonywane przez kompilacje ciągłej lub serwera.

• W przypadku gdy jest to praktyczne dla każdego kawałka funkcje zapisu jednostki najpierw przetestować.W tym przed opracowanie kod, który spełnia on.

Zaewidencjonuj zmiany

Przed sprawdzeniem jego zmiany, Peter używa Lync ponownie udostępnić jego ekran swojego współpracownika Julia, więc ona nieformalnie i interaktywnie przejrzeć z nim co został utworzony.Testy nadal fokus dyskusji, ponieważ Julia jest przede wszystkim zainteresowanym, w jaki kod tak, nie, jak to działa.Julia zgadza się, że co napisał Peter spełnia potrzeby jej.

Peter sprawdza wszystkie zmiany dokonał, włączając zarówno testy i kod i kojarzy je z zadań ukończył.Wyboru w kolejce zespołu zespołu zautomatyzowane kompilacji systemu do sprawdzania poprawności jego zmiany przy użyciu procesu tworzenia CI budowania zespołu.Ten proces budowania pomaga zespołu zminimalizować błędów w ich codebase przez tworzenie i testowanie — w oddzielnych ze swoich komputerów rozwoju czystego środowiska — zmiany, co sprawia, że zespół.

Peter powiadomienie po zakończeniu kompilacji.W wyniki kompilacji okna, zauważa, które powiodła się kompilacja i wszystkie testy przekazywane.

Aby zaewidencjonować zmiany

1. Na pasku menu wybierz widoku, Explorer zespołu.

2. W Explorer zespołu, wybierz polecenie domu , a następnie wybierz polecenie Moja praca.

3. Na Moja praca wybierz Sprawdź W.

4. Przejrzyj zawartość Oczekujące zmiany stronę, aby upewnić się, że:

   • Wszystkie istotne zmiany są wymienione w Uwzględnione zmiany

   • Wszystkie elementy stosowne prace są wymienione w Powiązane elementy pracy.

5. Określ komentarz , aby pomóc zespołowi zrozumieć te zmiany podczas przeglądania historii wersji formantu zmienione pliki i foldery.

6. Wybierz Sprawdź.

Aby zintegrować stale kod

Aby uzyskać więcej informacji na temat definiowania procesu tworzenia ciągłej integracji, zobacz Zdefiniowanie procesu tworzenia wspieranie ciągłej integracji.Po skonfigurowaniu tego procesu tworzenia można otrzymywać wyniki kompilacji zespołu.

Aby uzyskać więcej informacji, zobacz Uruchamianie, monitorowania i zarządzania kompilacje.

Dalej (zawieszenia pracy, błędów i przeprowadzenie przeglądu kodu)