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ę:

• Traktuj skrypty automatyzacji jako kod źródłowy i wersjonuj je razem z kodem aplikacji.
• Nigdy nie ewidencjonuj wpisów tajnych (poufnych danych, takich jak poświadczenia) w repozytorium kodu źródłowego.
• Skonfiguruj gałęzie źródłowe , aby włączyć przepływ pracy metodyki DevOps.

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

• Dodawanie skryptów do kontroli źródła w programie Visual Studio
• Przechowywanie poufnych danych na platformie Azure
• Korzystanie z usługi Git w programie Visual Studio 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:

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.

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 ).

Skopiuj pliki skryptów do folderu .

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

Dodaj pliki skryptów do folderu rozwiązania.

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:

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.

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

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ź.

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).

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

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.

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łąź.

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

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.

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

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:

• Tworzenie potoku wydania za pomocą serwera Team Foundation Server 2012. Dokumentacja dotycząca wzorców i praktyk firmy Microsoft. Zobacz rozdział 6, aby zapoznać się z omówieniem strategii rozgałęziania. Zwolennicy funkcji przełączają się na gałęzie funkcji, a jeśli gałęzie funkcji są używane, zwolennicy utrzymania ich krótkotrwałych (godzin lub dni w większości).
• Przewodnik kontroli wersji. Przewodnik po rozgałęzieniu strategii przez ALM Rangers. Zobacz Rozgałęzianie Strategies.pdf na karcie Pliki do pobrania.
• Programowanie oprogramowania z przełączaniem funkcji. Artykuł w magazynie MSDN.
• Przełącznik funkcji. Wprowadzenie do przełączania funkcji / flag funkcji na blogu Martina Fowlera.
• Przełączanie funkcji a gałęzie funkcji. Inny wpis w blogu o przełączeniach funkcji, autorstwa Dylana Smitha.

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:

• Najlepsze rozwiązania dotyczące wdrażania haseł i innych poufnych danych w ASP.NET i Azure App Service.
• Witryny sieci Web platformy Azure: jak działają parametry aplikacji i parametry połączenia. Objaśnia funkcję platformy Azure, która zastępuje appSettings dane connectionStrings w pliku Web.config .
• Niestandardowe ustawienia konfiguracji i aplikacji w witrynach sieci Web platformy Azure — w programie Stefan Schackow.

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.

WsteczDalej