원본 제어(Azure를 사용하여 Real-World Cloud Apps 빌드)

  • 아티클

작성자 : Rick Anderson, Tom Dykstra

수정 프로젝트 다운로드 또는 전자책 다운로드

Azure 전자책 을 사용하여 Real World Cloud Apps 빌드 는 Scott Guthrie가 개발한 프레젠테이션을 기반으로 합니다. 클라우드용 웹앱을 성공적으로 개발하는 데 도움이 될 수 있는 13개의 패턴과 사례를 설명합니다. 전자책에 대한 자세한 내용은 첫 번째 챕터를 참조하세요.

소스 제어는 팀 환경뿐만 아니라 모든 클라우드 개발 프로젝트에 필수적입니다. 실행 취소 함수 및 자동 백업이 없으면 소스 코드 또는 Word 문서를 편집할 필요가 없으며 소스 제어는 문제가 발생할 때 더 많은 시간을 절약할 수 있는 프로젝트 수준에서 해당 함수를 제공합니다. 클라우드 소스 제어 서비스를 사용하면 더 이상 복잡한 설정에 대해 걱정할 필요가 없으며 최대 5명의 사용자에게 Azure Repos 소스 제어를 무료로 사용할 수 있습니다.

이 챕터의 첫 번째 부분에서는 유의해야 할 세 가지 주요 모범 사례를 설명합니다.

챕터의 나머지 부분에서는 Visual Studio, Azure 및 Azure Repos 이러한 패턴의 몇 가지 샘플 구현을 제공합니다.

자동화 스크립트를 소스 코드로 처리

클라우드 프로젝트에서 작업할 때 자주 변경하고 고객이 보고한 문제에 신속하게 대응할 수 있기를 원합니다. 모든 항목 자동화 챕터에 설명된 대로 신속하게 응답하려면 자동화 스크립트를 사용해야 합니다. 환경을 만들고, 환경을 배포하고, 크기를 조정하는 데 사용하는 모든 스크립트는 애플리케이션 소스 코드와 동기화되어야 합니다.

스크립트를 코드와 동기화된 상태로 유지하려면 소스 제어 시스템에 저장합니다. 그런 다음 변경 내용을 롤백하거나 개발 코드와 다른 프로덕션 코드를 빠르게 수정해야 하는 경우 변경된 설정 또는 필요한 버전의 복사본이 있는 팀 구성원을 추적하는 데 시간을 낭비할 필요가 없습니다. 필요한 스크립트가 필요한 코드 베이스와 동기화되어 있고 모든 팀 구성원이 동일한 스크립트로 작업하고 있음을 확신할 수 있습니다. 그런 다음 프로덕션 또는 새 기능 개발에 대한 핫 픽스의 테스트 및 배포를 자동화해야 하는지 여부에 관계없이 업데이트해야 하는 코드에 적합한 스크립트가 있습니다.

비밀에 검사 않음

소스 코드 리포지토리는 일반적으로 너무 많은 사용자가 액세스할 수 있으므로 암호와 같은 중요한 데이터에 적절하게 안전한 위치가 될 수 있습니다. 스크립트가 암호와 같은 비밀을 사용하는 경우 소스 코드에 저장되지 않도록 해당 설정을 매개 변수화하고 비밀을 다른 곳에 저장합니다.

예를 들어 Azure를 사용하면 게시 프로필 만들기를 자동화하기 위해 게시 설정이 포함된 파일을 다운로드할 수 있습니다. 이러한 파일에는 Azure 서비스를 관리할 권한이 있는 사용자 이름 및 암호가 포함됩니다. 이 메서드를 사용하여 게시 프로필을 만들고 이러한 파일에서 소스 제어에 검사 경우 리포지토리에 액세스할 수 있는 모든 사용자가 해당 사용자 이름과 암호를 볼 수 있습니다. 암호는 암호화되고 기본적으로 소스 제어에 포함되지 않는 .pubxml.user 파일에 있으므로 게시 프로필 자체에 안전하게 저장할 수 있습니다.

DevOps 워크플로를 용이하게 하기 위한 원본 분기 구조화

리포지토리에서 분기를 구현하는 방법은 새로운 기능을 개발하고 프로덕션에서 문제를 해결하는 기능에 영향을 줍니다. 다음은 많은 중간 규모의 팀에서 사용하는 패턴입니다.

원본 분기 구조

기본 분기는 항상 프로덕션에 있는 코드와 일치합니다. 기본 아래의 분기는 개발 수명 주기의 여러 단계에 해당합니다. 개발 분기는 새 기능을 구현하는 위치입니다. 소규모 팀의 경우 기본 개발만 있을 수 있지만 개발과 기본 간에 준비 분기가 있는 것이 좋습니다. 업데이트를 프로덕션으로 이동하기 전에 최종 통합 테스트에 스테이징을 사용할 수 있습니다.

큰 팀의 경우 새로운 기능마다 별도의 분기가 있을 수 있습니다. 소규모 팀의 경우 모든 사용자가 개발 분기에 체크 인하도록 할 수 있습니다.

각 기능에 대한 분기가 있는 경우 기능 A가 준비되면 소스 코드 변경 내용을 개발 분기로 병합하고 다른 기능 분기로 축소합니다. 이 소스 코드 병합 프로세스는 시간이 오래 걸릴 수 있으며 기능을 별도로 유지하면서 해당 작업을 방지하기 위해 일부 팀은 기능 토글 ( 기능 플래그라고도 함)이라는 대체 기능을 구현합니다. 즉, 모든 기능에 대한 모든 코드가 동일한 분기에 있지만 코드의 스위치를 사용하여 각 기능을 사용하거나 사용하지 않도록 설정합니다. 예를 들어 기능 A가 앱 수정 작업의 새 필드이고 기능 B가 캐싱 기능을 추가한다고 가정합니다. 두 기능의 코드는 개발 분기에 있을 수 있지만 변수가 true로 설정된 경우에만 앱에서 새 필드를 표시하고 다른 변수가 true로 설정된 경우에만 캐싱을 사용합니다. 기능 A를 승격할 준비가 되지 않았지만 기능 B가 준비되면 기능 A 스위치가 꺼지고 기능 B가 켜진 상태에서 모든 코드를 프로덕션으로 승격할 수 있습니다. 그런 다음, 기능 A를 완료하고 소스 코드 병합 없이 나중에 승격할 수 있습니다.

기능에 분기 또는 토글을 사용하든 사용하지 않든 관계없이 이와 같은 분기 구조를 사용하면 개발에서 프로덕션으로 코드를 민첩하고 반복 가능한 방식으로 흐를 수 있습니다.

또한 이 구조를 사용하면 고객 피드백에 신속하게 대응할 수 있습니다. 프로덕션을 빠르게 수정해야 하는 경우 민첩한 방식으로 효율적으로 수정할 수도 있습니다. 기본 또는 스테이징에서 분기를 만들고 준비가 되면 개발 및 기능 분기로 기본 병합할 수 있습니다.

핫픽스 분기

프로덕션 분기와 개발 분기가 분리된 이와 같은 분기 구조가 없으면 프로덕션 문제로 인해 프로덕션 수정과 함께 새 기능 코드를 승격해야 하는 위치에 놓일 수 있습니다. 새 기능 코드가 완전히 테스트되고 프로덕션에 대해 준비되지 않았을 수 있으며 준비되지 않은 변경 내용을 백업하는 데 많은 작업을 수행해야 할 수 있습니다. 또는 변경 내용을 테스트하고 배포할 준비를 하려면 수정을 지연해야 할 수 있습니다.

다음으로 Visual Studio, Azure 및 Azure Repos 이러한 세 가지 패턴을 구현하는 방법의 예제를 볼 수 있습니다. 다음은 자세한 단계별 방법 지침이 아닌 예제입니다. 필요한 모든 컨텍스트를 제공하는 자세한 지침은 챕터 끝에 있는 리소스 섹션을 참조하세요.

Visual Studio에서 소스 제어에 스크립트 추가

Visual Studio 솔루션 폴더에 스크립트를 포함하여 Visual Studio의 소스 제어에 스크립트를 추가할 수 있습니다(프로젝트가 소스 제어에 있다고 가정). 이 작업을 수행하는 한 가지 방법은 다음과 같습니다.

솔루션 폴더( .sln 파일이 있는 동일한 폴더)에 스크립트에 대한 폴더를 만듭니다.

Automation 폴더

스크립트 파일을 폴더에 복사합니다.

Automation 폴더 내용

Visual Studio에서 프로젝트에 솔루션 폴더를 추가합니다.

새 솔루션 폴더 메뉴 선택

그리고 솔루션 폴더에 스크립트 파일을 추가합니다.

기존 항목 추가 메뉴 선택

기존 항목 추가 대화 상자

스크립트 파일은 이제 프로젝트에 포함되며 소스 제어는 해당 소스 코드 변경 내용과 함께 버전 변경 내용을 추적하고 있습니다.

Azure에 중요한 데이터 저장

Azure 웹 사이트에서 애플리케이션을 실행하는 경우 원본 제어에 자격 증명을 저장하지 않도록 하는 한 가지 방법은 대신 Azure에 저장하는 것입니다.

예를 들어 Fix It 애플리케이션은 프로덕션의 암호와 Azure Storage 계정에 대한 액세스를 제공하는 키를 포함하는 두 개의 연결 문자열을 Web.config 파일에 저장합니다.

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

이러한 설정에 대한 실제 프로덕션 값을 Web.config 파일에 배치하거나 Web.Release.config 파일에 배치하여 배포 중에 삽입하도록 Web.config 변환을 구성하는 경우 원본 리포지토리에 저장됩니다. 프로덕션 게시 프로필에 데이터베이스 연결 문자열을 입력하면 암호가 .pubxml 파일에 있습니다. (소스 제어에서 .pubxml 파일을 제외할 수 있지만 다른 모든 배포 설정을 공유하는 이점을 잃게 됩니다.)

Azure는 Web.config 파일의 appSettings 및 연결 문자열 섹션에 대한 대안을 제공합니다. Azure 관리 포털의 웹 사이트에 대한 구성 탭의 관련 부분은 다음과 같습니다.

appSettings 및 connectionStrings in Portal

이 웹 사이트에 프로젝트를 배포하고 애플리케이션을 실행하는 경우 Azure에 저장한 값이 Web.config 파일에 있는 값을 재정의합니다.

관리 포털 또는 스크립트를 사용하여 Azure에서 이러한 값을 설정할 수 있습니다. 모든 항목 자동화 챕터에서 본 환경 만들기 자동화 스크립트는 Azure SQL 데이터베이스를 만들고, 스토리지 및 SQL Database 연결 문자열을 가져오고, 이러한 비밀을 웹 사이트의 설정에 저장합니다.

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

실제 값이 원본 리포지토리에 유지되지 않도록 스크립트가 매개 변수화됩니다.

개발 환경에서 로컬로 실행하는 경우 앱은 로컬 Web.config 파일을 읽고 연결 문자열은 웹 프로젝트의 App_Data 폴더에 있는 LocalDB SQL Server 데이터베이스를 가리킵니다. Azure에서 앱을 실행하고 앱이 Web.config 파일에서 이러한 값을 읽으려고 하면 다시 가져오고 사용하는 것은 실제로 Web.config 파일에 있는 값이 아니라 웹 사이트에 저장된 값입니다.

Visual Studio 및 Azure DevOps에서 Git 사용

소스 제어 환경을 사용하여 앞에서 제시한 DevOps 분기 구조를 구현할 수 있습니다. 분산 팀의 경우 DVCS( 분산 버전 제어 시스템 )가 가장 적합할 수 있습니다. 다른 팀의 경우 중앙 집중식 시스템이 더 잘 작동할 수 있습니다.

Git 은 널리 사용되는 분산 버전 제어 시스템입니다. 소스 제어에 Git을 사용하는 경우 로컬 컴퓨터의 모든 기록과 함께 리포지토리의 전체 복사본이 있습니다. 많은 사람들이 네트워크에 연결되지 않은 경우 작업을 계속하는 것이 더 쉽기 때문에 커밋 및 롤백, 분기 만들기 및 전환 등을 계속할 수 있다는 것을 선호합니다. 네트워크에 연결된 경우에도 모든 것이 로컬일 때 분기를 만들고 분기를 전환하는 것이 더 쉽고 빠릅니다. 다른 개발자에게 영향을 주지 않고 로컬 커밋 및 롤백을 수행할 수도 있습니다. 또한 커밋을 서버에 보내기 전에 일괄 처리할 수 있습니다.

Azure ReposGit 및 Team Foundation 버전 제어(TFVC, 중앙 집중식 소스 제어)를 모두 제공합니다. 여기에서 Azure DevOps를 시작 합니다.

Visual Studio 2017에는 기본 제공 일류 Git 지원이 포함되어 있습니다. 작동 방식에 대한 빠른 데모는 다음과 같습니다.

Visual Studio에서 프로젝트를 연 상태에서 솔루션 탐색기 솔루션을 마우스 오른쪽 단추로 클릭한 다음 소스 제어에 솔루션 추가를 선택합니다.

소스 제어에 솔루션 추가

Visual Studio는 TFVC(중앙 버전 제어) 또는 Git을 사용할 것인지 묻습니다.

소스 제어 선택

Git을 선택하고 확인을 클릭하면 Visual Studio에서 솔루션 폴더에 새 로컬 Git 리포지토리를 만듭니다. 새 리포지토리에는 아직 파일이 없습니다. Git 커밋을 수행하여 리포지토리에 추가해야 합니다. 솔루션 탐색기 솔루션을 마우스 오른쪽 단추로 클릭한 다음 커밋을 클릭합니다.

Commit

Visual Studio는 커밋에 대한 모든 프로젝트 파일을 자동으로 스테이딩하고 포함된 변경 내용 창의 팀 Explorer 나열합니다. 커밋에 포함하지 않으려는 항목이 있는 경우 커밋을 선택하고 마우스 오른쪽 단추를 클릭한 다음 제외를 클릭할 수 있습니다.

팀 탐색기

커밋 주석을 입력하고 커밋을 클릭하면 Visual Studio에서 커밋을 실행하고 커밋 ID 표시합니다.

팀 Explorer 변경 내용

이제 리포지토리의 코드와 달라지도록 일부 코드를 변경하면 차이점을 쉽게 볼 수 있습니다. 변경한 파일을 마우스 오른쪽 단추로 클릭하고 수정 되지 않은 파일과 비교를 선택하면 커밋되지 않은 변경 내용을 보여 주는 비교 표시가 표시됩니다.

수정되지 않은 버전과 비교

변경 내용을 보여 주는 차이

변경 내용을 쉽게 확인하고 검사 수 있습니다.

분기를 만들어야 한다고 가정해 보겠습니다. Visual Studio에서도 그렇게 할 수 있습니다. 팀 Explorer새 분기를 클릭합니다.

팀 Explorer 새 분기 - 이미지 1

분기 이름을 입력하고 분기 만들기를 클릭한 다음 체크 아웃 분기를 선택하면 Visual Studio에서 새 분기를 자동으로 체크 아웃합니다.

팀 Explorer 새 분기 - 이미지 2

이제 파일을 변경하고 이 분기에 검사 수 있습니다. 또한 분기 간에 쉽게 전환할 수 있으며 Visual Studio는 체크 아웃한 분기와 파일을 자동으로 동기화합니다. 이 예제에서는 _Layout.cshtml 의 웹 페이지 제목이 HotFix1 분기의 "핫 픽스 1"로 변경되었습니다.

핫픽스1 분기

기본 분기로 다시 전환하면 _Layout.cshtml 파일의 내용이 기본 분기에 있는 내용으로 자동으로 되돌리기.

기본 분기

다음은 분기를 빠르게 만들고 분기 간에 앞뒤로 대칭 이동하는 방법의 간단한 예입니다. 이 기능을 사용하면 모든 항목 자동화 챕터에 표시된 분기 구조 및 자동화 스크립트를 사용하여 매우 민첩한 워크플로를 사용할 수 있습니다. 예를 들어 개발 분기에서 작업하고, 기본 핫 픽스 분기를 만들고, 새 분기로 전환하고, 변경한 후 커밋한 다음, 개발 분기로 다시 전환하여 수행한 작업을 계속할 수 있습니다.

여기에서 본 것은 Visual Studio에서 로컬 Git 리포지토리로 작업하는 방법입니다. 팀 환경에서는 일반적으로 변경 내용을 공통 리포지토리로 푸시합니다. Visual Studio 도구를 사용하면 원격 Git 리포지토리를 가리킬 수도 있습니다. 해당 목적을 위해 GitHub.com 사용하거나 작업 항목 및 버그 추적과 같은 다른 모든 Azure DevOps 기능과 통합된 Git 및 Azure Repos 사용할 수 있습니다.

물론 민첩한 분기 전략을 구현할 수 있는 유일한 방법은 아닙니다. 중앙 집중식 소스 제어 리포지토리를 사용하여 동일한 민첩한 워크플로를 사용하도록 설정할 수 있습니다.

요약

얼마나 빨리 변경하고 안전하고 예측 가능한 방식으로 라이브로 전환할 수 있는지에 따라 소스 제어 시스템의 성공을 측정합니다. 하루나 이틀 동안 수동 테스트를 수행해야 하기 때문에 변경을 두려워한다면 몇 분 안에 또는 최악의 경우 1시간 이내로 변경할 수 있도록 프로세스별 또는 테스트 측면에서 무엇을 해야 하는지 스스로에게 물어볼 수 있습니다. 이를 위한 한 가지 전략은 연속 통합 및 지속적인 업데이트를 구현하는 것이며, 다음 챕터에서 다룹니다.

리소스

분기 전략에 대한 자세한 내용은 다음 리소스를 참조하세요.

소스 제어 리포지토리에 보관해서는 안 되는 중요한 정보를 처리하는 방법에 대한 자세한 내용은 다음 리소스를 참조하세요.

중요한 정보를 소스 제어에서 벗어나게 하는 다른 방법에 대한 자세한 내용은 ASP.NET MVC: 개인 설정이 소스 제어에서 벗어나지 않도록 유지를 참조하세요.

이전다음