데이터베이스 개발 및 배포 전략(VB)

아티클
07/13/2023

처음으로 데이터 기반 애플리케이션을 배포할 때 개발 환경의 데이터베이스를 프로덕션 환경에 맹목적으로 복사할 수 있습니다. 그러나 후속 배포에서 블라인드 복사본을 수행하면 프로덕션 데이터베이스에 입력된 모든 데이터를 덮어씁니다. 대신, 데이터베이스를 배포하려면 마지막 배포 이후의 개발 데이터베이스 변경 내용을 프로덕션 데이터베이스에 적용해야 합니다. 이 자습서에서는 이러한 과제를 살펴보고 마지막 배포 이후의 변경 내용을 데이터베이스에 연대기화하고 적용하는 데 도움이 되도록 다양한 전략을 제공합니다.

소개

이전 자습서에서 설명한 대로 ASP.NET 애플리케이션을 배포하려면 개발 환경에서 프로덕션 환경으로 관련 콘텐츠를 복사해야 합니다. 배포는 일회성 이벤트가 아니라 새 버전의 소프트웨어가 릴리스되거나 버그 또는 보안 문제가 식별되고 해결될 때마다 발생하는 이벤트입니다. ASP.NET 페이지, 이미지, JavaScript 파일 및 기타 파일을 프로덕션 환경에 복사할 때는 마지막 배포 이후 이러한 파일이 어떻게 변경되었는지에 대해 걱정할 필요가 없습니다. 파일을 프로덕션 환경에 맹목적으로 복사하여 기존 콘텐츠를 덮어쓸 수 있습니다. 아쉽게도 이러한 단순성은 데이터베이스 배포로 확장되지 않습니다.

처음으로 데이터 기반 애플리케이션을 배포할 때 개발 환경의 데이터베이스를 프로덕션 환경에 맹목적으로 복사할 수 있습니다. 그러나 후속 배포에서 블라인드 복사본을 수행하면 프로덕션 데이터베이스에 입력된 모든 데이터를 덮어씁니다. 대신, 데이터베이스를 배포하려면 마지막 배포 이후의 개발 데이터베이스 변경 내용을 프로덕션 데이터베이스에 적용해야 합니다. 이 자습서에서는 이러한 과제를 살펴보고 마지막 배포 이후의 변경 내용을 데이터베이스에 연대기화하고 적용하는 데 도움이 되도록 다양한 전략을 제공합니다.

데이터베이스 배포의 과제

데이터 기반 애플리케이션이 처음으로 배포되기 전에는 데이터베이스, 즉 개발 환경에 데이터베이스가 하나만 있으므로 데이터 기반 애플리케이션을 처음으로 배포할 때 개발 환경의 데이터베이스를 프로덕션 환경에 맹목적으로 복사할 수 있습니다. 그러나 애플리케이션이 배포되면 두 개의 데이터베이스 복사본이 있습니다. 하나는 개발 중이고 다른 하나는 프로덕션에 있습니다.

배포 간에 개발 데이터베이스와 프로덕션 데이터베이스가 동기화될 수 있습니다. 프로덕션 데이터베이스의 스키마는 변경되지 않은 상태로 유지되지만 새 기능이 추가되면 개발 데이터베이스 스키마가 변경 될 수 있습니다. 열, 테이블, 뷰 또는 저장 프로시저를 추가하거나 제거할 수 있습니다. 개발 데이터베이스에 추가되는 중요한 데이터도 있을 수 있습니다. 많은 데이터 기반 애플리케이션에는 사용자가 편집할 수 없는 하드 코딩된 애플리케이션별 데이터로 채워진 조회 테이블이 포함됩니다. 예를 들어 경매 웹 사이트에는 경매 중인 항목의 상태를 설명하는 선택 항목인 New, Like New, Good 및 Fair가 포함된 드롭다운 목록이 있을 수 있습니다. 이러한 옵션을 드롭다운 목록에서 직접 하드 코딩하는 대신 일반적으로 데이터베이스 테이블에 배치하는 것이 좋습니다. 개발 중에 Poor라는 새 조건이 테이블에 추가되면 애플리케이션을 배포할 때 이 동일한 레코드를 프로덕션 데이터베이스의 조회 테이블에 추가해야 합니다.

이상적으로 데이터베이스를 배포하려면 개발에서 프로덕션으로 데이터베이스를 복사하는 것이 좋습니다. 그러나 애플리케이션을 배포하고 개발을 재개한 후 프로덕션 데이터베이스는 실제 사용자의 실제 데이터로 채워지고 있습니다. 따라서 다음 배포 시 개발에서 프로덕션으로 데이터베이스를 복사하기만 하면 프로덕션 데이터베이스를 덮어쓰고 기존 데이터를 잃게 됩니다. 결과적으로 데이터베이스 배포는 마지막 배포 이후 개발 데이터베이스에 변경된 내용을 적용하는 것으로 귀결됩니다.

데이터베이스 배포에는 스키마의 변경 내용과 마지막 배포 이후의 데이터 적용이 포함되므로 변경 내용을 프로덕션 환경에 적용할 수 있도록 변경 기록을 유지 관리(또는 배포 시 결정)해야 합니다. 데이터 모델에 변경 내용을 관리하고 적용하는 다양한 기술이 있습니다.

기준 정의

애플리케이션 데이터베이스에 대한 변경 내용을 유지하려면 변경 내용이 적용되는 기준인 시작 상태가 있어야 합니다. 한 가지 극단적인 경우 시작 상태는 테이블, 뷰 또는 저장 프로시저가 없는 빈 데이터베이스일 수 있습니다. 이러한 기준은 초기 배포 후 변경된 내용과 함께 모든 데이터베이스 테이블, 뷰 및 저장 프로시저 만들기를 포함해야 하기 때문에 큰 변경 로그를 생성합니다. 스펙트럼의 다른 쪽 끝에서 초기 프로덕션 환경에 배포된 데이터베이스의 버전으로 기준을 설정할 수 있습니다. 이렇게 선택하면 첫 번째 배포 후 데이터베이스에 대한 변경 내용만 포함되므로 변경 로그가 훨씬 더 작아집니다. 이것은 내가 선호하는 접근 방식입니다. 물론 데이터베이스를 처음 만드는 시점과 데이터베이스가 처음 배포된 시점 사이의 어느 시점으로 기준을 정의하여 도로 접근 방식의 중간을 선택할 수 있습니다.

기준을 선택한 후에는 기준 버전을 다시 만들기 위해 실행할 수 있는 SQL 스크립트를 생성하는 것이 좋습니다. 이러한 스크립트를 사용하면 데이터베이스의 기준 버전을 신속하게 다시 만들 수 있습니다. 이 기능은 프로젝트에서 작업하는 개발자가 여러 명 있거나 테스트 또는 스테이징과 같은 추가 환경이 있을 수 있는 대규모 프로젝트에서 특히 유용합니다. 각 프로젝트에는 자체 데이터베이스 복사본이 필요합니다.

기준 버전의 SQL 스크립트를 생성하기 위한 다양한 도구가 있습니다. SSMS(SQL Server Management Studio)에서 데이터베이스를 마우스 오른쪽 단추로 클릭하고 작업 하위 메뉴로 이동하여 스크립트 생성 옵션을 선택할 수 있습니다. 그러면 스크립트 마법사가 시작됩니다. 그러면 데이터베이스 개체를 만드는 SQL 명령이 포함된 파일을 생성하도록 지시할 수 있습니다. 또 다른 옵션은 데이터베이스 스키마뿐만 아니라 데이터베이스 테이블의 데이터를 만드는 SQL 명령을 생성할 수 있는 데이터베이스 게시 마법사입니다. 데이터베이스 게시 마법사는 데이터베이스 배포 자습서에서 자세히 검토되었습니다. 사용하는 도구에 관계없이 결국 필요한 경우 데이터베이스의 기준 버전을 다시 만드는 데 사용할 수 있는 스크립트 파일이 있어야 합니다.

산문의 데이터베이스 변경 내용 문서화

개발 단계에서 데이터 모델에 대한 변경 로그를 유지하는 가장 간단한 방법은 산문의 변경 내용을 기록하는 것입니다. 예를 들어 이미 배포된 애플리케이션을 개발하는 동안 테이블에 새 열을 추가하고, 테이블에서 열을 EmployeesOrders 제거하고, 새 테이블(ProductCategories)을 추가하는 경우 텍스트 파일 또는 Microsoft Word 문서를 다음 기록과 함께 유지 관리합니다.

변경 날짜	세부 정보 변경
2009-02-03:	테이블에 열 `DepartmentID` (`int`NOT NULL)이 추가되었습니다 `Employees` . 에서 `Departments.DepartmentIDEmployees.DepartmentID`에 외래 키 제약 조건을 추가했습니다.
2009-02-05:	테이블에서 열 `TotalWeight` 이 `Orders` 제거되었습니다. 연결된 레코드에 이미 캡처된 `OrderDetails` 데이터입니다.
2009-02-12:	`ProductCategories` 테이블을 만들었습니다. 세 개의 열이 있습니다. `ProductCategoryID` (`int`, `IDENTITY`, `NOT NULL`), `CategoryName` (`nvarchar(50)`, `NOT NULL`), 및 `Active` (`bit`, `NOT NULL`). 에 기본 키 제약 조건을 `ProductCategoryID`추가하고 기본값인 1을 에 `Active`추가했습니다.

이 방법에는 여러 가지 단점이 있습니다. 우선 자동화에 대한 희망은 없습니다. 애플리케이션이 배포되는 경우와 같이 이러한 변경 내용을 데이터베이스에 적용해야 하는 경우 개발자는 각 변경 내용을 한 번에 하나씩 수동으로 구현해야 합니다. 또한 변경 로그를 사용하여 기준선에서 특정 버전의 데이터베이스를 다시 구성해야 하는 경우 로그 크기가 증가함에 따라 시간이 점점 더 많이 소요됩니다. 이 메서드의 또 다른 단점은 각 변경 로그 항목의 명확성과 세부 수준이 변경 내용을 기록하는 사람에게 남아 있다는 것입니다. 개발자가 여러 명 있는 팀에서는 다른 개발자보다 더 상세하거나, 읽기 가능하거나, 더 정확한 항목을 만들 수 있습니다. 또한 오타 및 기타 인간 관련 데이터 입력 오류가 발생할 수 있습니다.

산문에서 데이터베이스 변경 내용을 문서화하는 주요 이점은 단순성입니다. 데이터베이스 개체를 만들고 변경하기 위한 SQL 구문을 잘 알고 있어야 합니다. 대신 산문의 변경 내용을 기록하고 SQL Server Management Studio 그래픽 사용자 인터페이스를 통해 구현할 수 있습니다.

산문에서 변경 로그를 유지 관리하는 것은 매우 정교하지 않으며, scope 큰 프로젝트와 같이 특정 프로젝트에서 잘 작동하지 않거나, 데이터 모델을 자주 변경하거나, 여러 개발자가 참여합니다. 그러나 이 방법은 데이터 모델을 가끔씩만 변경하고 솔로 개발자가 데이터베이스 개체를 만들고 변경하기 위한 SQL 구문에 강력한 배경 지식이 없는 소규모 1인 프로젝트에서 잘 작동하는 것을 보았습니다.

참고

변경 로그의 정보는 기술적으로 배포 시간까지만 필요하지만 변경 기록을 유지하는 것이 좋습니다. 그러나 계속 증가하는 단일 변경 로그 파일을 유지 관리하는 대신 각 데이터베이스 버전에 대해 다른 변경 로그 파일을 갖는 것이 좋습니다. 일반적으로 데이터베이스가 배포될 때마다 데이터베이스의 버전을 지정하려고 합니다. 변경 로그 로그를 유지 관리하면 기준부터 버전 1부터 시작하여 다시 만들어야 하는 버전에 도달할 때까지 계속하여 변경 로그 스크립트를 실행하여 데이터베이스 버전을 다시 만들 수 있습니다.

SQL 변경 문 기록

산문에서 변경 로그를 유지하는 주요 단점은 자동화가 부족하다는 것입니다. 배포 시 프로덕션 데이터베이스에 대한 데이터베이스 변경 내용을 구현하는 것이 지침 목록을 수동으로 수행하지 않고 스크립트를 실행하는 단추를 클릭하는 것만큼 쉽습니다. 이러한 자동화는 데이터 모델을 변경하는 데 사용되는 SQL 명령이 포함된 변경 로그를 유지 관리하여 가능합니다.

SQL 구문에는 다양한 데이터베이스 개체를 만들고 수정하기 위한 여러 문이 포함되어 있습니다. 예를 들어 CREATE TABLE 문을 실행하면 지정된 열과 제약 조건이 있는 새 테이블을 만듭니다. ALTER TABLE 문은 기존 테이블을 수정하고 열 또는 제약 조건을 추가, 제거 또는 수정합니다. 인덱스, 뷰, 사용자 정의 함수, 저장 프로시저, 트리거 및 기타 데이터베이스 개체를 만들고 수정하고 삭제하는 문도 있습니다.

이전 예제로 돌아가서 이미 배포된 애플리케이션을 개발하는 동안 테이블에 새 열을 추가하고 테이블에서 열을 EmployeesOrders 제거하고 새 테이블(ProductCategories)을 추가합니다. 이러한 작업을 수행하면 다음 SQL 명령이 포함된 변경 로그 파일이 생성됩니다.

-- Add the DepartmentID column 

ALTER TABLE [Employees] ADD [DepartmentID] 
int NOT NULL 

-- Add a foreign key constraint between Departments.DepartmentID and Employees.DepartmentID
ALTER TABLE [Employees] ADD 
CONSTRAINT [FK_Departments_DepartmentID]
      FOREIGN 
KEY ([DepartmentID]) 
      REFERENCES 
[Departments] ([DepartmentID]) 

-- Remove TotalWeight column from Orders
ALTER TABLE [Orders] DROP COLUMN 
[TotalWeight] 

-- Create the ProductCategories table

CREATE TABLE [ProductCategories]
(
      [ProductCategoryID] 
int IDENTITY(1,1) NOT NULL,
      [CategoryName] 
nvarchar(50) NOT NULL,
      [Active] 
bit NOT NULL CONSTRAINT [DF_ProductCategories_Active]  DEFAULT 
((1)),
      CONSTRAINT 
[PK_ProductCategories] PRIMARY KEY CLUSTERED ( [ProductCategoryID])
)

배포 시 프로덕션 데이터베이스에 이러한 변경 내용을 푸시하는 작업은 한 번의 클릭 작업입니다. SQL Server Management Studio 열고, 프로덕션 데이터베이스에 연결하고, 새 쿼리 창을 열고, 변경 로그의 내용을 붙여넣고, 실행을 클릭하여 스크립트를 실행합니다.

비교 도구를 사용하여 데이터 모델 동기화

산문에서 데이터베이스 변경 내용을 문서화하는 것은 쉽지만 변경 내용을 구현하려면 개발자가 프로덕션 데이터베이스를 한 번에 하나씩 변경해야 합니다. 변경 SQL 명령을 문서화하면 프로덕션 데이터베이스에서 이러한 변경 내용을 단추를 클릭하는 것만큼 쉽고 빠르게 구현할 수 있지만 데이터베이스 개체를 만들고 변경하려면 SQL 문과 구문을 학습하고 마스터해야 합니다. 데이터베이스 비교 도구는 두 방법 모두에서 가장 잘 사용하고 최악의 경우를 무시합니다.

데이터베이스 비교 도구는 두 데이터베이스의 스키마 또는 데이터를 비교하고 데이터베이스의 차이점을 보여 주는 요약 보고서를 표시합니다. 그런 다음 단추를 클릭하면 하나 이상의 데이터베이스 개체를 동기화하기 위한 SQL 명령을 생성할 수 있습니다. 간단히 말해서 데이터베이스 비교 도구를 사용하여 배포 시 개발 데이터베이스와 프로덕션 데이터베이스를 비교할 수 있으며, 실행될 때 개발 데이터베이스 스키마를 미러링하도록 프로덕션 데이터베이스 스키마에 변경 내용을 적용하는 SQL 명령이 포함된 파일을 생성할 수 있습니다.

다양한 공급업체에서 제공하는 다양한 타사 데이터베이스 비교 도구가 있습니다. 이러한 예 중 하나는 RED Gate Software의 SQL Compare입니다. SQL 비교를 사용하여 개발 및 프로덕션 데이터베이스 스키마를 비교하고 동기화하는 프로세스를 살펴보겠습니다.

참고

이 작성 당시 SQL Compare의 현재 버전은 버전 7.1이었으며 Standard Edition의 비용은 $395입니다. 무료 14일 평가판을 다운로드하여 팔로우할 수 있습니다.

SQL 비교가 시작되면 비교 프로젝트 대화 상자가 열리고 저장된 SQL 비교 프로젝트가 표시됩니다. 새 프로젝트를 만듭니다. 그러면 비교할 데이터베이스에 대한 정보를 묻는 프로젝트 구성 마법사가 시작됩니다(그림 1 참조). 개발 및 프로덕션 환경 데이터베이스에 대한 정보를 입력합니다.

그림 1: 개발 및 프로덕션 데이터베이스 비교(전체 크기 이미지를 보려면 클릭)

참고

개발 환경 데이터베이스가 웹 사이트의 폴더에 있는 App_Data SQL Express Edition 데이터베이스 파일인 경우 그림 1에 표시된 대화 상자에서 선택하려면 SQL Server Express 데이터베이스 서버에 데이터베이스를 등록해야 합니다. 이 작업을 수행하는 가장 쉬운 방법은 SQL Server Management Studio(SSMS)을 열고, SQL Server Express 데이터베이스 서버에 연결하고, 데이터베이스를 연결하는 것입니다. 컴퓨터에 SSMS가 설치되어 있지 않은 경우 무료 SQL Server Management Studio 다운로드하여 설치할 수 있습니다.

비교할 데이터베이스를 선택하는 것 외에도 옵션 탭에서 다양한 비교 설정을 지정할 수도 있습니다. 설정할 수 있는 한 가지 옵션은 "제약 조건 및 인덱스 이름 무시"입니다. 이전 자습서에서는 개발 및 프로덕션 데이터베이스에 애플리케이션 서비스 데이터베이스 개체를 추가했습니다. 이 도구를 사용하여 aspnet_regsql.exe 프로덕션 데이터베이스에서 이러한 개체를 만든 경우 기본 키와 고유 제약 조건 이름이 개발 데이터베이스와 프로덕션 데이터베이스 간에 다르다는 것을 알게 됩니다. 따라서 SQL Compare는 모든 애플리케이션 서비스 테이블에 다른 플래그를 지정합니다. "제약 조건 및 인덱스 이름 무시"를 선택 취소하고 제약 조건 이름을 동기화하거나 SQL Compare에 이러한 차이점을 무시하도록 지시할 수 있습니다.

비교할 데이터베이스를 선택하고 비교 옵션을 검토한 후 지금 비교 단추를 클릭하여 비교를 시작합니다. 다음 몇 초 동안 SQL Compare는 두 데이터베이스의 스키마를 검사하고 차이점에 대한 보고서를 생성합니다. SQL Compare 인터페이스에서 이러한 불일치를 표시하는 방법을 보여주기 위해 개발 데이터베이스를 의도적으로 수정했습니다. 그림 2에서 알 수 Authors 있듯이 테이블에 열을 추가하고BirthDate, 테이블에서 열을 Books 제거하고ISBN, 사이트를 방문하는 사용자가 검토한 책의 속도를 평가할 수 있도록 하는 새 테이블 Ratings를 추가했습니다.

참고

이 자습서에서 변경된 데이터 모델은 데이터베이스 비교 도구를 사용하여 설명하기 위해 수행되었습니다. 향후 자습서에서는 이러한 변경 내용을 데이터베이스에서 찾을 수 없습니다.

그림 2: SQL 비교 Lists 개발 데이터베이스와 프로덕션 데이터베이스 간의 차이점(전체 크기 이미지를 보려면 클릭)

SQL 비교는 데이터베이스 개체를 그룹으로 구분하여 두 데이터베이스에 존재하지만 서로 다른 개체, 한 데이터베이스에 존재하는 개체, 다른 데이터베이스에는 존재하지 않는 개체 및 동일한 개체를 빠르게 보여 줍니다. 보듯이 두 데이터베이스에 모두 존재하지만 서로 다른 Authors 두 개체가 있습니다. 즉, 열이 추가된 테이블과 Books 제거된 테이블이 있습니다. 개발 데이터베이스에만 존재하는 하나의 개체, 즉 새로 만든 Ratings 테이블이 있습니다. 또한 두 데이터베이스에서 동일한 117개의 개체가 있습니다.

데이터베이스 개체를 선택하면 이러한 개체의 차이점을 보여 주는 SQL 차이점 창이 표시됩니다. 그림 2의 맨 아래에 표시된 SQL 차이점 창은 BirthDate 개발 데이터베이스의 Authors 테이블에 프로덕션 데이터베이스의 테이블에 없는 Authors 열이 있음을 강조 표시합니다.

차이점을 검토하고 동기화할 개체를 선택한 후 다음 단계는 개발 데이터베이스와 일치하도록 프로덕션 데이터베이스 스키마를 업데이트하는 데 필요한 SQL 명령을 생성하는 것입니다. 이 작업은 동기화 마법사를 통해 수행됩니다. 동기화 마법사는 동기화할 개체를 확인하고 작업 계획을 요약합니다(그림 3 참조). 데이터베이스를 즉시 동기화하거나 여가 시간에 실행할 수 있는 SQL 명령을 사용하여 스크립트를 생성할 수 있습니다.

그림 3: 동기화 마법사를 사용하여 데이터베이스 스키마 동기화(전체 크기 이미지를 보려면 클릭)

Red Gate Software의 SQL Compare와 같은 데이터베이스 비교 도구는 개발 데이터베이스 스키마의 변경 내용을 프로덕션 데이터베이스에 포인트만큼 쉽게 적용하고 클릭합니다.

참고

SQL 비교는 두 데이터베이스 스키마를 비교하고 동기화합니다. 아쉽게도 두 데이터베이스 테이블 내의 데이터를 비교하고 동기화하지는 않습니다. Red Gate Software는 두 데이터베이스 간의 데이터를 비교하고 동기화하는 SQL Data Compare 라는 제품을 제공하지만 SQL Compare와는 별도의 제품이며 다른 $395의 비용이 듭니다.

배포하는 동안 애플리케이션을 오프라인으로 전환

이 자습서 전체에서 살펴본 것처럼 배포는 개발 환경에서 프로덕션 환경으로 ASP.NET 페이지, master 페이지, CSS 파일, JavaScript 파일, 이미지 및 기타 필요한 콘텐츠 복사, 필요한 경우 프로덕션 환경별 구성 정보 복사, 마지막 배포 이후 데이터 모델에 변경 내용 적용 등 여러 단계를 포함하는 프로세스입니다. 파일 수와 데이터베이스 변경의 복잡성에 따라 이러한 단계를 완료하는 데 몇 초에서 몇 분 정도 걸릴 수 있습니다. 이 창에서 웹 애플리케이션이 유동적이고 사이트를 방문하는 사용자에게 오류 또는 예기치 않은 동작이 발생할 수 있습니다.

웹 사이트를 배포할 때 배포가 완료될 때까지 웹 애플리케이션을 "오프라인"으로 만드는 것이 가장 좋습니다. 애플리케이션을 오프라인으로 전환하고 배포 프로세스가 완료되면 다시 가져오는 것은 파일을 업로드한 다음 삭제하는 것만큼 쉽습니다. ASP.NET 2.0부터 애플리케이션 루트 디렉터리에 라는 app_offline.htm 파일의 단순한 존재는 전체 웹 사이트를 "오프라인"으로 만듭니다. 해당 사이트의 ASP.NET 페이지에 대한 모든 요청은 파일 내용 app_offline.htm 으로 자동으로 응답됩니다. 해당 파일이 제거되면 애플리케이션이 다시 온라인 상태가됩니다.

배포하는 동안 애플리케이션을 오프라인으로 전환하면 배포 프로세스를 시작하기 전에 파일을 프로덕션 환경의 루트 디렉터리에 업로드 app_offline.htm 한 다음 배포가 완료되면 삭제(또는 다른 이름으로 변경)하는 것만큼 간단합니다. 이 기술에 대한 자세한 내용은 John Peterson의 문서인 ASP.NET 애플리케이션을 오프라인으로 전환을 참조하세요.

요약

데이터베이스 배포를 중심으로 데이터 기반 애플리케이션 센터를 배포하는 기본 과제입니다. 개발 환경에 하나와 프로덕션 환경에 하나씩 두 가지 버전의 데이터베이스가 있기 때문에 이 두 데이터베이스 스키마는 개발에 새로운 기능이 추가됨에 따라 동기화되지 않습니다. 또한 프로덕션 데이터베이스가 실제 사용자의 실제 데이터로 채워지므로 애플리케이션을 구성하는 파일(ASP.NET 페이지, 이미지 파일 등)을 배포할 때처럼 수정된 개발 데이터베이스로 프로덕션 데이터베이스를 덮어쓸 수 없습니다. 대신 데이터베이스를 배포하려면 마지막 배포 이후 프로덕션 데이터베이스에서 개발 데이터베이스에 대한 정확한 변경 내용 집합을 구현해야 합니다.

이 자습서에서는 데이터베이스 변경 로그를 유지 관리하고 적용하는 세 가지 기술을 살펴보았습니다. 가장 간단한 방법은 산문의 변경 내용을 기록하는 것입니다. 이 전술은 프로덕션 데이터베이스에서 이러한 변경 내용을 수동 프로세스로 구현하지만 데이터베이스 개체를 만들고 변경하기 위한 SQL 명령에 대한 지식이 필요하지는 않습니다. 보다 정교한 접근 방식과 여러 개발자가 있는 대규모 프로젝트 또는 프로젝트에서 훨씬 더 맛있게 사용할 수 있는 방법은 변경 내용을 일련의 SQL 명령으로 기록하는 것입니다. 이렇게 하면 이러한 변경 내용을 대상 데이터베이스에 배포하는 작업이 크게 서두르고 있습니다. Red Gate Software의 SQL Compare와 같은 데이터베이스 비교 도구를 사용하여 두 방법 중 가장 좋은 방법을 달성할 수 있습니다.

이 자습서에서는 데이터 기반 애플리케이션을 배포하는 데 중점을 두고 있습니다. 다음 자습서 집합에서는 프로덕션 환경의 오류에 대응하는 방법을 살펴봅니다. 노란색 죽음의 화면 대신 친숙한 오류 페이지를 표시하는 방법을 살펴보겠습니다. 오류 세부 정보를 기록하는 방법과 이러한 오류가 발생할 때 경고하는 방법을 살펴보겠습니다.

행복한 프로그래밍!

이전 다음