다단계 배포를위한 팀 도시 모범 사례는 무엇입니까?

Question

우리는 3 개 환경을 가지고

• 개발 : Subversion을 트렁크에 커밋에 대한 팀시는 여기에 배포합니다.
• 준비 : 사용자 승인은 릴리스 후보 인 빌드에서 수행됩니다.
• 제작 : UAT가 통과되면 통과 코드 세트가 여기에 배포됩니다.

Team City를 사용하고 있으며 개발 환경과의 지속적인 통합 설정 만하고 있습니다. Team City가 수행하는 모든 개발 배포에 대한 아티팩트를 저장하고 싶지 않습니다. 배정 된 사람이 준비 서버를 성공적으로 개발 배포하도록 배포 구성을 시작할 수있게하고 싶습니다.

그런 다음 각 준비 배포에서 아티팩트를 저장하려고합니다. 준비 배포가 UAT를 통과하면 해당 패키지를 프로덕션에 배포하려고합니다.

Team City에서 설정하는 방법을 잘 모르겠습니다. 6.5.4 버전을 사용하고 있으며 "Promote ..."액션/트리거가 있음을 알고 있지만 저장된 아티팩트에 따라 다르다고 생각합니다. 매번 개발 배포를 아티팩트로 저장할 필요는 없지만 준비 배포를 실행하는 사람이 어떤 성공적인 개발 배포를 준비에 적용 할 것인지 지정할 수 있어야합니다.

여러 가지 방법이있을 수 있습니다. 모범 사례가 있습니까? 귀하의 설정은 무엇이며 왜 권장합니까?

업데이트 :

지금까지 하나의 답을 가지고 있고, 우리가 내부적으로 간주 한 아이디어입니다. 어떤 사람이 Team City 자체를 통해 스테이징/프로덕션 환경에 배포하기위한 다소 자동화 된 방법을 가지고 있는지 알고 싶습니다. 특정 역할/권한을 가진 사람 만이 수동으로 모든 것을 처리하지 않고 프로덕션에 배포 스크립트를 실행할 수 있습니다. 종류의 이슈 패키지. 누군가?

업데이트 2

나는 아직도 수상 현상금 1 일이 있고, 나는 대답은 아래 내 질문에 대답하지 않았다 생각했지만, 그것을 다시 읽기 후에 나는 내가 생각했던 내 질문에 아니라고 볼

였다.

Staging/Production 환경에 일종의 자동 배포를 위해 Team City를 사용할 수있는 방법이 있습니까?

Answer 1

실제로 두 가지 질문을하고 있습니다. 하나는 TeamCity 빌드에 대한 액세스 권한을 제어하는 ​​것이고 다른 하나는 이슈 관리의 물류에 관한 것입니다.

---

에 관한 권한, 당신이 무엇을 의미하는 가정 "특정 역할 만 명/생산에 배포 스크립트를 실행할 수있는 권한"과 줄리앙에 대한 당신의 반응은 당신이 아마의 devs 생산에 직접 배포하지 않을 것입니다 그러나 을 수행하면은 프로젝트에서 다른 빌드를 볼 수 있기를 원합니다. 이것은 IT 부서가 TeamCity에서 프로세스를 "오프라인"으로 처리하는 줄리안의 시나리오와 유사 할 수도 있습니다. IT 부서의 업무를 수행하는 IT 부서와 완전히 별개의 완전히 비효율적 인 프로세스를 사용해야한다고 주장 할 때 "이는 우리가 그렇게하는 방식입니다. "- 나 그 시작하지 않음)

을 문제가 인 TeamCity의 모든 권한이 프로젝트에 대해 적용되는 것을 당신이 당신의 빌드 모두와 함께 하나 개의 프로젝트를 빌드 없어 한 적이 그렇다면 간단! , 개발자 빌드와 제작 빌드에 대한 사용 권한 세분화 기능을 적용 할 수있는 기능이 없습니다. 저는 이전에 두 가지 방법으로이 문제를 처리했습니다 :

1. 사회적으로 다루십시오. 모든 사람들은 자신의 책임이 무엇인지 알고 있으며, 자신이하지 말아야 할 것을 실행하지 않습니다. 그렇게하면 감사되고 추적 할 수 있습니다. 성숙 단계, 책임에 대한 분명한 생각, 그리고 그것을 금지하는 준수 요건이 아닌 경우 잘 수행하십시오.
2. 별도의 프로젝트를 만듭니다. 이 작업을 수행하는 것을 좋아하지 않지만 은으로 문제를 해결합니다. 다른 프로젝트의 아티팩트를 계속 사용할 수 있습니다. 즉, 모든 개발자가 액세스 할 수있는 환경에 배포하는 빌드와 민감한 환경에 대한 다른 프로젝트를 포함하는 빌드가 포함 된 프로젝트로 끝나는 것입니다. 단점은 프로덕션 빌드가 실패하면 지원을 원하는 사람들이 액세스 할 수 없다는 것입니다.

---

는 유물 관리에 관해서는, 당신이 용량에 대한 걱정이 있다면 마지막 X 빌드에서만 유물을 유지하는 청소 정책을 정의, 개발 빌드에서 이러한 유지에 문제가 없습니다. 많은 사람들이 동일한 컴파일 된 결과를 모든 환경에 배포한다는 확실성을 원합니다. 즉, 일단 빌드하면 나중에 사용하기 위해 계속 유지하려고합니다.

dev 배포에서 이러한 인공물을 얻었 으면 별도의 빌드를 통해 다른 환경에 다시 배포 할 수 있습니다.구성 변환에 문제가있을 것입니다 (사용하고 있다고 가정). 주소를 처리하는 방법에 대한 아이디어는 this 2 part series입니다. 아직 자세히 설명하지는 않았지만 올바른 방향에 있다고 생각합니다.).

질문에 대한 답변이 있습니까? 아직 빠진 것이 있습니까?

Answer 2

TeamCity를 빌드 서버로 사용 했으므로 설정을 설명하겠습니다. 우리는 배포 검사 및 일부 UAT

생산

에 대한 준비 서버 환경 테스트 목적으로

QA

에서 커밋을 확인하기 위해 개발자가 사용하는 4 개 환경

• 개발이 우리 TeamCity를 사용하여 개발 (야간 빌드) 및 QA (주문형)에만 배포하십시오. Dev 빌드는 트렁크 분기를 사용하고 QA 빌드는 RC에 사용되는 다른 분기를 사용합니다.

  스테이징 및 프로덕션에 대한 배포는 IT 팀에서 관리하므로 자동화되지 않습니다.

  대신 TeamCity를 사용하여 QA 빌드에서 이슈를 생성합니다. 아티팩트는 준비/프로덕션 배포를 위해 보낸 배포 키트입니다.

  그렇다면 TeamCity가 어떤 빌드가 어떤 환경으로 승격 될 수 있는지에 대한 완전한 제어권을 제공하는지 확신 할 수 없습니다. 우리는 기본적으로 지점이있는 SVN 측면에서이를 제어하고 해당 분기에 대해 다른 빌드를 사용합니다. 같은 방식으로 관리 할 수 ​​있어야합니다. 따라서 무엇이 배포되고 있는지 확인할 수 있습니다.

  본인은 귀하의 필요 사항이 본사와 약간 다를 수 있음을 이해하지만, 귀하에게 최선의 설정을 찾는 데 도움이되기를 바랍니다.

Answer 3

Octopus Deploy 또는 BuildMaster과 같은 것을 체크 아웃하는 것이 좋습니다. 이들은 자동화하려는 배치 사례에 대한 훌륭한 구조를 제공합니다. 두 도구 모두 TeamCity와 잘 통합됩니다.

기본적으로 CI 용 TeamCity를 계속 사용하고 TeamCity를 사용하여 개발 환경에도 계속 배포 할 수 있지만 배포 도구 중 하나를 사용하여 (기존) 빌드를 준비로 승격 시키십시오 및 생산.

편집 2014년 2월 5일 - 업데이트

BuildMaster의 업체가 새로운 배포 기능이 - ProGet Deploy을 - 자신의 NuGet 서버 도구, ProGet합니다. Octopus Deploy와 매우 흡사합니다. 아직 직접 연주하지 않았으므로 Octopus는 어떤 버전이 어떤 환경에 배포되었는지 더 잘 보여줄 수 있습니다. 그 중요한 기능 때문에 아직도 BuildMaster를 사용합니다.

또한 TeamCity, BuildMaster 및 ProGet을 모두 사용하고 있으며 자동 빌드가없는 것으로 돌아가고 싶지 않습니다. 현재 모든 앱은 BuildMaster를 통해 빌드 및 배포됩니다. 내 모든 도서관 프로젝트는 TeamCity에 구축되어 ProGet에 배포됩니다. NuGet 인프라를 통해 내부 종속성을 관리 할 수 ​​있다는 것은 입니다.