다른 사용자가 DEV에서 DEVEST로 PROD로 코드 승격을 관리하는 방법에 궁금합니다.엔터프라이즈 환경에서 응용 프로그램 승격 프로세스 관리를 돕는 도구
사물의 "적색 테이프"출입구 기준 측면을 관리하는 데 사용하는 도구 또는 프로세스는 무엇입니까?
내 현재 조직은 문서를 제출하고 승인 및 검토를 받기 위해 일부 사용자 지정 온라인 양식 유형 기능과 종이 기반 종속성 사이에 끼어 있습니다.
응용 프로그램을 다음 단계로 승격시킬 수 있기 전에 "간과 된"승인이 필요한로드 블록이 있으면 제출 된 항목, 검토 된 항목, 승인 된 항목 및 관리자에게 조언을 제공하기 위해이 모든 것이 프로젝트 관리자에게 남겨집니다. 환경.
브라우저 기반 응용 프로그램이 이상적 일 것입니다. 당신이 googlefu가 내 것보다 낫다는 것을 보여주세요.
구글을 통해 좋은 것을 찾기가 어렵습니다. 문제 관리를위한 다양한 도구가 있으므로 사용하는 것과 언급 할 내용을 언급 할 것입니다.
현재 세레나 제품을 사용하고 있습니다. 그들은 과거에 우리를 위해 잘 일해 왔습니다. 팀 트랙은 문제 관리이며 우리가 작업하는 모든 문제의 라이프 사이클을 처리합니다. 버전 관리자는 우리의 소스 컨트롤이며 DEV TEST 및 PROD와 같은 프로모션 그룹을 구현하는 기능을 갖추고 있습니다. 우리는 DEV, TSTAGE, TEST, PSTAGE 및 PROD를 사용하여 움직임을 하나씩 나타냅니다. 그러나 거의 동일합니다. 두 제품은 문제와 관련된 소스가 연결되도록 멋지게 통합되지만이 환경에서는 빌드 프로세스 설정이 없습니다. 비싸지 만 잘 작동합니다.
우리는 문제 관리를 위해 Jira, 소스 제어를 위해 Subversion, 두 가지를 함께 연결하는 Fisheye 및 빌드 관리를 위해 Cruise Control을 사용하여보다 일반적인 시스템으로 이동하려고합니다. 이것은 덜 비싸며, 엔터프라이즈 라이 센스에 대해 수천 개의 합계를 가지며 동일한 기능을 제공하지만 SVN의 보너스가 추가되어 매우 훌륭한 코드 버전의 mangager입니다.
도움이 되었기를 바랍니다.
나는 지난 몇 년 동안 경험했던 몇 가지 시나리오가 있습니다
데브 -> 테스트 : 새로운 기능에 대한 작업을 중지하고 테스트 환경을 가지고있는 코드를 가져옵니다 코드 동결 기간은 일반적으로있다 내장 된 태그가 붙어 있거나 라벨이 붙어 있거나 보관 처리되었습니다. 그런 다음 컴퓨터에 복사되고 테스트가 정상적으로 진행됩니다. 이것은 또한 일반적으로 모든 푸시에 대해 가장 상세하지 않습니다.
테스트 -> 생산성 : 생산이 중단되어야하는 사소한 변경이 필요합니다. 이는 "낚시를 마쳤어"페이지가 올라 갔거나 IIS가 사이트를 실행하지 않고 코드가 다시 복사된다는 것을 의미 할 수 있습니다. 로드 밸런서가 스위치로 작동하여 프로모션이 발생하고 세션이 끝나면 이전 서버의 이벤트가 중단되므로 다운 타임이 발생하지 않는 특별한 경우가 있습니다.
스위치 아이디어에 대해 자세히 설명하자면,로드 밸런서가 한 트래픽을 다른 서버에 업데이트 할 때 전환 할 수있는 하나의 서버로 요청하는 서버가 하나 뿐인 서버가 2 대의 라이브 서버로 구성되어야합니다 살기위한 코드.
테스트와 프로덕션 사이에있는 준비 환경이있을 수 있습니다.이 환경은 프로모션이 발생하는 날짜가 정해져 있다는 점에서 프로세스가 유사합니다.
개발자가 Perforce 병합 코드에서 대부분의 시간을 소비하여 한 환경에서 다른 환경으로 승격시킬 수있는 병합 일이있었습니다.
지금이 사용되지 않는 경우 몇 가지가 있습니다 :
"핫픽스"또는 내가 작업하는 데 사용 여기서 "핫 패치"가 발생할 것이며,이 경우 특정 파일이 준비들로 복사 된 제작 환경이 파손되었거나 2 분이 걸리는 새로운 작업을 완료했기 때문에 코드 변경이 최대한 빨리 생산에 들어 있어야했기 때문에 생산 환경 자체가 자체적으로 수행되었습니다. 이 경우 푸시 된 코드 변경 사항을 검토하고 승인해야합니다.
이러한 접근 방식은 일반적으로 일정과 일정이 잠재적으로 변경되어야하거나 회의가 특정 주말에있는 것처럼 어려운 날짜를 만들기 위해 추가 리소스가 필요했던 곳에서 사용 된 것과 같은 방식입니다. 준비 됐어.
물론 몇 군데에서 "아, 그게 망가 졌나요? 내가 보게 ..."하고 몇 분 후, "아니, 내게 부러지지 말라."누군가 회사가 여전히 "카우보이 프로그래밍 (cowboy programming)"이라고 부르는 부분이있는 허가 또는 기타 사항을 묻지 않고 바뀌 었습니다.
또 다른 점은 릴리스의 스케일입니다 : 1) 작은 - 소수 또는 파일 때문에 - 이것은 해당 사용자 X가 Y를에게
2) 작은 작업을 수행 할 수 있도록 하나의 웹 페이지가 상승의 경우 그건 정말 복잡하지는 않지만 사소한 것은 아닙니다.
3) 중간 - 한 환경에서 다른 환경으로 이동하려면 여러 파일을 변경해야하며 대개 이동 스크립트가 있어야합니다.
4) 빅 - 예정된 프로모션이 있고 다양한 개발자가 누가 라이브 푸시가 수행 될 때 어떤 변화를 취하고 있는지 묻습니다. 새로운 전자 상거래 사이트를 출시하는 것 외에도 데이터 이전이 필요한 경우이 작업을 수행했습니다.
5) Mammoth - 모든 것이 새로운 방식으로 사용되는 방법을 포함하여 새로운 것입니다. 나는이 크기 중 하나를 본 적이 없다고 생각하지만 Microsoft 또는 Google이이 크기의 릴리스를 제공한다고 생각합니다.
스펙트럼의 대부분은 가을에 출시되므로 계획과 준비가 어느 정도 다를 수 있으며 규정 준수가 일부 작업을 완료하는 데 자체적으로 어려움을 겪을 수 있음을 잊지 마시기 바랍니다.