Udostępnij za pośrednictwem


Kontrola źródła (tworzenie aplikacji w chmurze Real-World za pomocą platformy Azure)

Autor : Rick Anderson, Tom Dykstra

Pobierz naprawę projektu lub pobierz książkę elektroniczną

Książka elektroniczna Building Real World Cloud Apps with Azure (Tworzenie rzeczywistych aplikacji w chmurze za pomocą platformy Azure ) jest oparta na prezentacji opracowanej przez Scotta Guthrie. Wyjaśniono w nim 13 wzorców i rozwiązań, które mogą pomóc w pomyślnym tworzeniu aplikacji internetowych dla chmury. Aby uzyskać informacje na temat książki e-book, zobacz pierwszy rozdział.

Kontrola źródła jest niezbędna dla wszystkich projektów programistycznych w chmurze, a nie tylko środowisk zespołowych. Nie myślisz o edytowaniu kodu źródłowego, a nawet Word dokumencie bez funkcji cofania i automatycznych kopii zapasowych, a kontrola źródła zapewnia te funkcje na poziomie projektu, gdzie mogą zaoszczędzić jeszcze więcej czasu, gdy coś pójdzie nie tak. Dzięki usługom kontroli źródła w chmurze nie musisz już martwić się o skomplikowaną konfigurację i możesz użyć Azure Repos kontroli źródła bezpłatnie dla maksymalnie 5 użytkowników.

W pierwszej części tego rozdziału opisano trzy najważniejsze najlepsze rozwiązania, które należy wziąć pod uwagę:

W pozostałej części rozdziału przedstawiono przykładowe implementacje tych wzorców w programie Visual Studio, na platformie Azure i Azure Repos:

Traktuj skrypty automatyzacji jako kod źródłowy

Podczas pracy nad projektem w chmurze często zmieniasz elementy i chcesz szybko reagować na problemy zgłaszane przez klientów. Szybkie reagowanie obejmuje korzystanie ze skryptów automatyzacji, jak wyjaśniono w rozdziale Automatyzowanie wszystkiego . Wszystkie skrypty używane do tworzenia środowiska, wdrażania w nim, skalowania itp., muszą być zsynchronizowane z kodem źródłowym aplikacji.

Aby zachować synchronizację skryptów z kodem, zapisz je w systemie kontroli źródła. Następnie, jeśli kiedykolwiek trzeba wycofać zmiany lub wprowadzić szybką poprawkę do kodu produkcyjnego, który różni się od kodu programistycznego, nie musisz tracić czasu na śledzenie, które ustawienia zostały zmienione lub którzy członkowie zespołu mają kopie potrzebnej wersji. Masz pewność, że potrzebne skrypty są zsynchronizowane z bazą kodu, której potrzebujesz, i masz pewność, że wszyscy członkowie zespołu pracują z tymi samymi skryptami. Następnie niezależnie od tego, czy musisz zautomatyzować testowanie i wdrażanie poprawki gorącej w środowisku produkcyjnym, czy w przypadku tworzenia nowych funkcji, będziesz mieć odpowiedni skrypt dla kodu, który należy zaktualizować.

Nie ewidencjonuj wpisów tajnych

Repozytorium kodu źródłowego jest zwykle dostępne dla zbyt wielu osób, aby było odpowiednio bezpiecznym miejscem dla poufnych danych, takich jak hasła. Jeśli skrypty bazują na wpisach tajnych, takich jak hasła, parametryzują te ustawienia, aby nie były zapisywane w kodzie źródłowym i przechowywać wpisy tajne w innym miejscu.

Na przykład platforma Azure umożliwia pobieranie plików zawierających ustawienia publikowania w celu zautomatyzowania tworzenia profilów publikowania. Te pliki obejmują nazwy użytkowników i hasła, które są autoryzowane do zarządzania usługami platformy Azure. Jeśli używasz tej metody do tworzenia profilów publikowania, a jeśli zaewidencjonujesz te pliki do kontroli źródła, każda osoba mająca dostęp do repozytorium będzie widzieć te nazwy użytkowników i hasła. Hasło można bezpiecznie przechowywać w samym profilu publikowania, ponieważ jest ono zaszyfrowane i znajduje się w pliku .pubxml.user , który domyślnie nie jest uwzględniany w kontroli źródła.

Struktura gałęzi źródłowych ułatwiających przepływ pracy metodyki DevOps

Sposób implementowania gałęzi w repozytorium wpływa na możliwość tworzenia nowych funkcji i rozwiązywania problemów w środowisku produkcyjnym. Oto wzorzec, którego używa wiele średnich zespołów:

Struktura gałęzi źródłowej

Gałąź główna zawsze pasuje do kodu, który znajduje się w środowisku produkcyjnym. Gałęzie poniżej głównej odpowiadają różnym etapom cyklu życia programowania. Gałąź programowania to miejsce, w którym wdrażasz nowe funkcje. W przypadku małego zespołu możesz po prostu mieć główny i deweloperski , ale często zalecamy, aby ludzie mieli gałąź przejściową między programowaniem a głównym. Możesz użyć etapu przejściowego na potrzeby końcowego testowania integracji przed przeniesieniem aktualizacji do środowiska produkcyjnego.

W przypadku dużych zespołów mogą istnieć oddzielne gałęzie dla każdej nowej funkcji; w przypadku mniejszego zespołu może istnieć możliwość zaewidencjonowania wszystkich użytkowników w gałęzi programowania.

Jeśli masz gałąź dla każdej funkcji, gdy funkcja A jest gotowa, scalasz jego kod źródłowy w gałęzi programowania i w dół do innych gałęzi funkcji. Ten proces scalania kodu źródłowego może być czasochłonny i w celu uniknięcia tej pracy przy zachowaniu oddzielnych funkcji niektóre zespoły implementują alternatywne przełączenia nazywane funkcjami (znane również jako flagi funkcji). Oznacza to, że cały kod dla wszystkich funkcji znajduje się w tej samej gałęzi, ale włączasz lub wyłączasz każdą funkcję za pomocą przełączników w kodzie. Załóżmy na przykład, że funkcja A to nowe pole do naprawiania zadań aplikacji, a funkcja B dodaje funkcje buforowania. Kod dla obu funkcji może znajdować się w gałęzi programowania, ale aplikacja będzie wyświetlać nowe pole tylko wtedy, gdy zmienna jest ustawiona na wartość true, i będzie używać buforowania tylko wtedy, gdy inna zmienna jest ustawiona na wartość true. Jeśli funkcja A nie jest gotowa do podwyższenia poziomu, ale funkcja B jest gotowa, możesz podwyższyć poziom całego kodu do środowiska produkcyjnego z wyłączeniem funkcji A i włączeniem funkcji B. Następnie możesz zakończyć funkcję A i podwyższyć jej poziom później— wszystko bez scalania kodu źródłowego.

Niezależnie od tego, czy używasz gałęzi, czy przełączania dla funkcji, struktura rozgałęziania, taka jak ta, umożliwia przepływ kodu z programowania do środowiska produkcyjnego w sposób elastyczny i powtarzalny.

Ta struktura umożliwia również szybkie reagowanie na opinie klientów. Jeśli potrzebujesz szybkiej poprawki do środowiska produkcyjnego, możesz to również zrobić wydajnie w sposób elastyczny. Można utworzyć gałąź z gałęzi main lub przejściowej, a gdy będzie gotowa scalić ją z gałęzią główną i w dół do gałęzi programowania i funkcji.

Gałąź poprawek

Bez takiej struktury rozgałęziania z podziałem gałęzi produkcyjnych i programistycznych problem produkcyjny może spowodować konieczność promowania nowego kodu funkcji wraz z poprawką produkcyjną. Nowy kod funkcji może nie być w pełni przetestowany i gotowy do użycia w środowisku produkcyjnym. Może być konieczne wykonanie wielu prac nad wycofywaniem zmian, które nie są gotowe. Możesz też opóźnić poprawkę, aby przetestować zmiany i przygotować je do wdrożenia.

Następnie zobaczysz przykłady implementacji tych trzech wzorców w programie Visual Studio, na platformie Azure i Azure Repos. Są to przykłady, a nie szczegółowe instrukcje krok po kroku dotyczące wykonywania instrukcji; Aby uzyskać szczegółowe instrukcje, które dostarczają wszystkie niezbędne konteksty, zobacz sekcję Zasoby na końcu rozdziału.

Dodawanie skryptów do kontroli źródła w programie Visual Studio

Skrypty można dodawać do kontroli źródła w programie Visual Studio, dołączając je do folderu rozwiązania programu Visual Studio (przy założeniu, że projekt jest w kontroli źródła). Oto jeden ze sposobów, aby to zrobić.

Utwórz folder dla skryptów w folderze rozwiązania (tym samym folderze, który ma plik sln ).

Folder automatyzacji

Skopiuj pliki skryptów do folderu .

Zawartość folderu usługi Automation

W programie Visual Studio dodaj folder rozwiązania do projektu.

Wybór menu Nowy folder rozwiązania

Dodaj pliki skryptów do folderu rozwiązania.

Wybieranie menu Dodaj istniejący element

Okno dialogowe Dodawanie istniejącego elementu

Pliki skryptów są teraz uwzględniane w projekcie, a kontrola źródła śledzi ich zmiany wersji wraz z odpowiednimi zmianami kodu źródłowego.

Przechowywanie poufnych danych na platformie Azure

Jeśli uruchamiasz aplikację w witrynie internetowej platformy Azure, jednym ze sposobów uniknięcia przechowywania poświadczeń w kontroli źródła jest przechowywanie ich na platformie Azure.

Na przykład aplikacja Fix It przechowuje w swoim Web.config dwa parametry połączenia, które będą miały hasła w środowisku produkcyjnym i klucz, który zapewnia dostęp do konta usługi Azure Storage.

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

Jeśli umieścisz rzeczywiste wartości produkcyjne dla tych ustawień w pliku Web.config lub jeśli umieścisz je w pliku Web.Release.config w celu skonfigurowania przekształcenia Web.config w celu wstawienia ich podczas wdrażania, będą one przechowywane w repozytorium źródłowym. Jeśli wprowadzisz parametry połączenia bazy danych do profilu publikowania produkcyjnego, hasło będzie znajdować się w pliku pubxml . (Możesz wykluczyć plik pubxml z kontroli źródła, ale utracisz korzyść z udostępniania wszystkich innych ustawień wdrożenia).

Platforma Azure udostępnia alternatywę dla sekcji appSettings i parametrów połączenia w pliku Web.config . Oto odpowiednia część karty Konfiguracja witryny internetowej w portalu zarządzania Platformy Azure:

appSettings i connectionStrings w portalu

Po wdrożeniu projektu w tej witrynie internetowej i uruchomieniu aplikacji wszystkie wartości przechowywane na platformie Azure zastępują wszystkie wartości w pliku Web.config.

Te wartości można ustawić na platformie Azure przy użyciu portalu zarządzania lub skryptów. Skrypt automatyzacji tworzenia środowiska, który został wyświetlony w rozdziale Automatyzowanie wszystkiego, tworzy bazę danych Azure SQL, pobiera magazyn i SQL Database parametry połączenia oraz przechowuje te wpisy tajne w ustawieniach witryny internetowej.

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}
# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

Zwróć uwagę, że skrypty są sparametryzowane, aby rzeczywiste wartości nie zostały utrwalone w repozytorium źródłowym.

Po uruchomieniu lokalnie w środowisku projektowym aplikacja odczytuje lokalny plik Web.config, a parametry połączenia są wskazywane na bazę danych localDB SQL Server w folderze App_Data projektu internetowego. Gdy uruchomisz aplikację na platformie Azure, a aplikacja próbuje odczytać te wartości z pliku Web.config, to, co zostanie odzyskane i używane, to wartości przechowywane dla witryny sieci Web, a nie to, co jest rzeczywiście w pliku Web.config.

Korzystanie z usługi Git w programie Visual Studio i usłudze Azure DevOps

Możesz użyć dowolnego środowiska kontroli źródła do zaimplementowania przedstawionej wcześniej struktury rozgałęziania DevOps. W przypadku zespołów rozproszonych rozproszony system kontroli wersji (DVCS) może działać najlepiej; w przypadku innych zespołów scentralizowany system może działać lepiej.

Git to popularny rozproszony system kontroli wersji. Gdy używasz narzędzia Git do kontroli źródła, masz pełną kopię repozytorium ze całą jego historią na komputerze lokalnym. Wiele osób woli to, ponieważ łatwiej jest kontynuować pracę, gdy nie masz połączenia z siecią — możesz nadal wykonywać zatwierdzenia i wycofywanie, tworzyć i przełączać gałęzie itd. Nawet po nawiązaniu połączenia z siecią łatwiej i szybciej jest tworzyć gałęzie i przełączać gałęzie, gdy wszystko jest lokalne. Możesz również wykonywać lokalne zatwierdzenia i wycofywanie bez wpływu na innych deweloperów. Zatwierdzenia wsadowe można również wykonać przed wysłaniem ich do serwera.

Azure Repos oferuje zarówno usługę Git, jak i Kontrola wersji serwera Team Foundation (TFVC; scentralizowaną kontrolę źródła). Rozpocznij pracę z usługą Azure DevOps tutaj.

Program Visual Studio 2017 obejmuje wbudowaną, pierwszą klasę obsługę usługi Git. Oto krótki pokaz tego, jak to działa.

Po otwarciu projektu w programie Visual Studio kliknij prawym przyciskiem myszy rozwiązanie w Eksplorator rozwiązań, a następnie wybierz polecenie Dodaj rozwiązanie do kontroli źródła.

Dodawanie rozwiązania do kontroli źródła

Program Visual Studio pyta, czy chcesz użyć serwera TFVC (scentralizowanej kontroli wersji) lub usługi Git.

Wybieranie kontroli źródła

Po wybraniu pozycji Git i kliknięciu przycisku OK program Visual Studio utworzy nowe lokalne repozytorium Git w folderze rozwiązania. Nowe repozytorium nie ma jeszcze żadnych plików; Musisz dodać je do repozytorium, wykonując zatwierdzenie usługi Git. Kliknij prawym przyciskiem myszy rozwiązanie w Eksplorator rozwiązań, a następnie kliknij przycisk Zatwierdź.

Zatwierdzenie

Program Visual Studio automatycznie etapuje wszystkie pliki projektu dla zatwierdzenia i wyświetla je w programie Team Explorer w okienku Uwzględnione zmiany . (Jeśli nie chcesz uwzględnić niektórych elementów w zatwierdzeniu, możesz je wybrać, kliknąć prawym przyciskiem myszy i kliknąć przycisk Wyklucz).

Team Explorer

Wprowadź komentarz zatwierdzenia, a następnie kliknij pozycję Zatwierdź, a program Visual Studio wykonuje zatwierdzenie i wyświetla identyfikator zatwierdzenia.

Zmiany programu Team Explorer

Teraz, jeśli zmienisz kod tak, aby różnił się od tego, co znajduje się w repozytorium, możesz łatwo wyświetlić różnice. Kliknij prawym przyciskiem myszy zmieniony plik, wybierz pozycję Porównaj z niezmodyfikowanym i zostanie wyświetlony ekran porównania pokazujący niezatwierdzone zmiany.

Porównanie z niezmodyfikowanym

Różnice pokazujące zmiany

Możesz łatwo zobaczyć, jakie zmiany wprowadzasz i zaewidencjonować.

Załóżmy, że musisz utworzyć gałąź — możesz to zrobić również w programie Visual Studio. W programie Team Explorer kliknij pozycję Nowa gałąź.

Nowa gałąź programu Team Explorer — obraz 1

Wprowadź nazwę gałęzi, kliknij pozycję Utwórz gałąź, a jeśli wybrano gałąź wyewidencjonowania, program Visual Studio automatycznie wyewidencjonuje nową gałąź.

Nowa gałąź programu Team Explorer — obraz 2

Teraz możesz wprowadzić zmiany w plikach i zaewidencjonować je w tej gałęzi. Ponadto można łatwo przełączać się między gałęziami i programem Visual Studio automatycznie synchronizuje pliki z wyewidencjonowana gałęzią. W tym przykładzie tytuł strony internetowej w pliku _Layout.cshtml został zmieniony na "Poprawka 1" w gałęzi HotFix1.

Gałąź Poprawka1

Jeśli wrócisz do gałęzi głównej , zawartość pliku _Layout.cshtml zostanie automatycznie przywrócona do gałęzi głównej .

gałąź główna

Jest to prosty przykład szybkiego tworzenia gałęzi i przerzucania między gałęziami. Ta funkcja umożliwia wysoce zwinny przepływ pracy przy użyciu struktury gałęzi i skryptów automatyzacji przedstawionych w rozdziale Automatyzowanie wszystkiego . Na przykład możesz pracować w gałęzi Programowanie, utworzyć gałąź naprawy gorącą poza gałęzią główną, przełączyć się do nowej gałęzi, wprowadzić tam zmiany i zatwierdzić je, a następnie wrócić do gałęzi Programowanie i kontynuować to, co robisz.

W tym miejscu przedstawiono sposób pracy z lokalnym repozytorium Git w programie Visual Studio. W środowisku zespołowym zwykle wypychasz również zmiany do wspólnego repozytorium. Narzędzia programu Visual Studio umożliwiają również wskazanie zdalnego repozytorium Git. W tym celu można użyć GitHub.com lub użyć narzędzia Git i Azure Repos zintegrowanego ze wszystkimi innymi funkcjami usługi Azure DevOps, takimi jak element roboczy i śledzenie błędów.

Nie jest to jedyny sposób, w jaki można zaimplementować zwinną strategię rozgałęziania, oczywiście. Możesz włączyć ten sam zwinny przepływ pracy przy użyciu scentralizowanego repozytorium kontroli źródła.

Podsumowanie

Zmierz sukces systemu kontroli źródła na podstawie tego, jak szybko możesz wprowadzić zmianę i uzyskać go na żywo w bezpieczny i przewidywalny sposób. Jeśli znajdziesz się przestraszony, aby wprowadzić zmianę, ponieważ musisz zrobić dzień lub dwa testy ręczne na nim, możesz zadać sobie pytanie, co musisz zrobić, mądry proces lub test mądry, aby można było wprowadzić te zmiany w minutach lub w najgorszym czasie nie dłużej niż godzinę. Jedną ze strategii, która polega na zaimplementowaniu ciągłej integracji i ciągłego dostarczania, które omówimy w następnym rozdziale.

Zasoby

Aby uzyskać więcej informacji na temat strategii rozgałęziania, zobacz następujące zasoby:

Aby uzyskać więcej informacji na temat obsługi poufnych informacji, które nie powinny być przechowywane w repozytoriach kontroli źródła, zobacz następujące zasoby:

Aby uzyskać informacje o innych metodach utrzymywania poufnych informacji poza kontrolą źródła, zobacz ASP.NET MVC: Zachowywanie ustawień prywatnych poza kontrolą źródła.