.NET 배포 열반을 달성하려면 어떻게 해야 합니까?

https://stackoverflow.com/questions/997878

13-09-2019
|

문제

우리 회사는 "실행" 날짜(및 QA 부서 날짜 지정)가 가까워지고 있으며 이를 지원하기 위한 올바른 운영 프로세스를 정의하려고 노력 중입니다.제가 가장 중요하게 생각하는 점은 필연적으로 발생하는 배포/구성 지옥을 피하는 방법입니다.QA, 스테이징 및 프로덕션 환경에서 성공적으로 설치하고 구성할 수 있도록 프로그래머가 아닌 사람들에게 빌드를 전달하는 좋은 솔루션을 찾은 사람이 있습니까?

우리의 전체 환경은 이기종의 예약된 작업, Windows 서비스 및 웹 사이트의 혼합으로 구성되며, 모두 병렬 배포를 통해 확장할 수 있습니다.고맙게도 구성 방법은 일관됩니다.불행하게도 이 모든 것은 .NET web/app.config 파일을 통해 관리됩니다.내 경험에 따르면 QA 및 운영 담당자는 수정하려고 할 때 항상 혼란을 겪습니다. (XML은 대부분의 사람들이 처리하기 놀랍게도 어렵습니다!)

제가 고려하고 있는 옵션은 다음과 같습니다.

machine.config 파일 사용

이것은 실제로 해본 적이 없지만 유망해 보입니다.환경에 따라 달라질 수 있는 모든 애플리케이션에 대한 모든 설정을 포함하는 machine.config 템플릿을 생성하면 관리자가 하나의 파일에 대한 모든 변경 사항을 적용하고 환경의 각 시스템에 배포할 수 있습니다.

장점:: 이는 잠재적으로 시스템 배포에 필요한 단계 수를 줄여줍니다.
단점:: 어떻게든 구성 스키마 변경 사항을 문서화해야 함
알 수 없는 것:: 우리는 어셈블리를 참조하는 사용자 지정 구성 섹션과 기타 구성 확장을 사용합니다.이를 위해서는 컴퓨터의 GAC에 .NET 어셈블리를 설치해야 합니까?

빌드 프로세스에서 구성 파일 조작 수행

QA, 스테이징 및 프로덕션 환경을 설정하여 소프트웨어(가상 서버 및 LAN 등)와 동일하게 보이도록 하면 QA는 구성 변경 없이 준비된 소프트웨어를 스테이징 환경으로 직접 전환하고 스테이징을 프로덕션으로 전환할 수 있어야 합니다. .이 설정을 사용하면 이론적으로 누구도 건드릴 필요가 없는 사전 구성된 foo.config 파일을 QA에 전달할 수 있습니다.

장점:: 엔지니어링은 구성 파일이 유효한지 확인하는 데 더 능숙합니다.
단점:: 엔지니어링이 생산 구성을 인식하는 것은 열악한 보안 관행으로 간주될 수 있습니다(잘못된 주장, IMHO)

네트워크 중앙 집중식 설정 저장소 보유

이것은 나에게 매력적으로 보이지 않습니다. 왜냐하면 나는 세 가지 방법으로 시도했지만 결국 실패했기 때문입니다.

이전 회사에서는 데이터베이스에 구성 설정이 있었지만 물론 연결 문자열을 구성해야 하기 때문에 모든 것을 거기에 넣을 수는 없었습니다. 에게 그 데이터베이스.또한 배포 전에 데이터베이스가 제대로 업데이트되었는지 확인하는 것도 마찬가지로 어려웠습니다.
우리가 시도한 또 다른 접근 방식은 일종의 중앙 집중식 레지스트리처럼 작동하는 네트워크 서비스를 갖는 것이었습니다.이는 거의 효과가 있었지만 구성 서버에 대한 URL이 올바르게 구성되었는지 확인하고 구성 서버를 구성하는 로컬 캐싱에는 항상 문제가 있었습니다.
액티브 디렉토리?에!더 말할 필요가 있나요?

생각?

제가 고려 중인 옵션을 사용하여 얼마나 성공적이셨나요?당신에게 효과가 있었던 대안이 있습니까?

해결책

우리는 우리가 사용하는 빌드 이후에 실행되는 커스텀 exe를 가지고 있습니다.

우리 프로젝트에는 4 개의 구성 파일이 있습니다

web.config- 개발 (로컬 박스)
web.integration.config- 알파 테스트 (알파 서버에서 실행)
web.staging.config- 베타 테스트 (베타 서버에서 실행)
web.production.config- 생산 (생산 서버에서 실행)

EXE는 필요한 파일을 제외한 모든 파일을 단순히 삭제 한 다음 web.config로 이름을 바꿉니다.

비 개발자 (QA, DBA 등)는 프로덕션 값 (Mail Server, SQL Server)으로 변경할 수 있으므로 구성 파일을 조작하고 심각한 문제를 일으킬 수 있도록 구성 파일을 조작 할 수 없습니다.

그것은 우리에게 매우 잘 작동합니다

다른 팁

나는 몇 가지 일을한다고 말하고 싶습니다.

먼저 준비 서버를 사용하십시오. 엔지니어링 또는 비 엔지니어링의 경우 코드의 "모의 배포"를 서버로 수행하는 위치와 여기에서 테스트되는 위치가 있습니다. 이는 테스트 할 독특한 "생산과 같은"환경을 제공하는 것이 좋습니다.이를 통해 모든 사람이 배포에 모든 것을 핵무기에 대한 두려움으로 인해 모든 사람이 모든 이상하고 흔들리지 않고 배치 교육을받을 수 있습니다. 하드웨어 측면에서는 조금 더 비쌉니다. 그러나 아마도 방지하는 오류로부터 가치가있을 것입니다.

둘째, 구성 파일이 진정으로 복잡하고 엔지니어가 아닌 사람이 구성하기 어려운 경우 배포를위한 유효성 검사 파일을 생성하는 빠른 도구를 작성하십시오. 기본 배포 매개 변수를 취하고 유효성 검사를 수행 한 다음 적절한 형식으로 모든 것을 저장하는 간단한 웹 사이트 또는 클라이언트 측 앱은 덜 기술적 인 사람들을 돕는 데있어 놀라운 형식으로 모든 것을 저장합니다. 입력을 검증하는 도구가 이러한 유형의 사람들에게 유용 할 수 있다는 확신과 검증 된 결과를 가진 잘 형성된 XML을 가질 것이라는 사실을 알고 있으면 엔지니어 걱정 시간도 절약 할 수 있습니다.

회사는 배포 스크립트와 가상 머신을 사용하여 생산을 반영하여 QA 빌드 및 버튼 프레스에서 배치 된 빌드를 준비하는 것을 보았습니다. PowerShell을 사용하여이를 수행 할 수 있습니다.

나는 항상 로컬 및 데이터베이스 구동 설정 스토리지의 혼합으로 성공했습니다. 기계 별 설정은 애플리케이션 별 (사용자 별) 설정과 마찬가지로 시스템의 XML 파일 (루트 데이터베이스에 대한 연결 정보가 포함되어 있음)에 저장되었습니다. 사용자 별 또는 엔터프라이즈 전체 설정은 다른 데이터베이스에 대한 연결 정보를 포함하여 데이터베이스에 저장되었습니다. 다시 말해,이 정보가 포함 된 단일 데이터베이스가 있었는데,이 데이터베이스는 클라이언트가 다른 데이터베이스에 연결하는 데 사용할 수 있습니다. 이를 통해 루트 데이터베이스에 대한 연결을 제외한 모든 것을 중앙에서 유지할 수있었습니다.

이전 회사에서는 다음을 구현했습니다.

개발자는 각 앱에 대한 마스터 구성 파일을 만듭니다.
머신/환경별 토큰을 식별하고 이를 별도의 파일로 옮깁니다.
CI 시스템은 체크아웃을 수행하고 파일에 새 버전 번호를 태그 지정하고 테스트를 실행한 다음 변경 관리 담당자가 제어하는 중앙 공유에 애플리케이션을 복사합니다.
변경 관리는 깔끔한 배포 대시보드를 불러옵니다.그런 다음 원하는 앱, 요청한 버전, 요청한 환경을 선택합니다.그런 다음 이동 버튼을 눌렀습니다.
배포 앱은 준비된 파일 공유의 모든 파일을 서버로 복사합니다.
그런 다음 배포 앱은 빌드 스크립트에서 추가 작업을 시작합니다.
NAnt 스크립트는 각 대상 컴퓨터에 복사된 다음 P/Invoke를 사용하여 시작되었습니다.

모든 것은 Anthill, NAnt, Robocopy 및 배포를 조정하는 경량 맞춤형 앱을 사용하여 구현되었습니다.사용

이것의 가장 큰 장점은 수동 배포 단계가 거의 없었다는 것입니다.개발 배포부터 모든 것이 반복 가능하고 테스트 가능했습니다.

이를 위해 최대한 격리시키려고 노력했습니다.우리는 GAC와 machine.configs를 대부분 피했습니다.시간이 지남에 따라 모든 앱이 반드시 새 버전의 공유 구성 요소로 이동하기를 원하지 않았기 때문에 이것이 속도에 상당히 도움이 된다는 것을 알게 되었습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow