소프트웨어 개발의 환경 명명 표준?

15

내 프로젝트는 현재 환경 명명 문제로 고통 받고 있습니다. 사람들마다 이름을 지정해야하는 환경이나 이름이 지정하는 것에 대해 다른 가정이 있으며, 환경을 논의 할 때 혼동을 일으 킵니다. 나는 약간의 연구를 해왔으며 거기에서 어떤 표준도 찾지 못했습니다.

"Local", "Sand", "Dev", "Test", "User", "QA", "Staging"및 "Prod"라는 용어가 포함됩니다.

나는 단지 의견을 찾고있는 것이 아니라, "모두"가 가지고 있다고 생각하는 것이 있다면 비공식적이라하더라도 일종의 권위에 의해 발전된 정의를 찾으려고 노력하고 있습니다.

현재 사용중인 환경은 다음과 같습니다.

개발자 PC의 환경
개발자가 직접 자체 테스트에 코드를 업로드하는 공유 환경
품질 관리 담당자가 표준 및 기능을 테스트하는 공유 환경
완료 및 QA 확인 코드가 프로젝트 요청자가 승인 한 공유 환경
최종 점검으로 최종 환경을 반영하고 배치를 준비하는 환경
코드가 사용되는 최종 환경

나는 그들이 무엇 을 부를지 알고 있지만 이것에 대한 표준이 있습니까? 미리 감사드립니다.

development-environment naming-standards

— Marcus_33
소스

감사. 나는 그 SE를 몰랐다. 나는 그것이 ServerFault 또는 SuperUser에 속하지 않는다는 것을 알고 있었지만 전에는 programmers.se에 대해 들어 본 적이 없습니다.

나는 그것을 이동으로 표시 했으므로 이상적으로 올바른 사이트로가는 길을 찾으십시오.

— Ricardo Altamirano

프로젝트 범위에 따라 환경이 더 적거나 더 많을 수 있습니다.

— Yusubov

11

고정 된 표준뿐만 아니라 고정 된 패턴도 없습니다. 당신이 만들고있는 것과 그것을 복제 할 수있는 규모 사이의 의존성은 어떤 종류의 프로젝트에서 다른 프로젝트로 어떻게 보일지를 지시 할 것입니다.

나는 최소한 하나의 환경과 최대 13 개의 환경에서 작업했습니다.

당신이 묘사하는 순서에서 나는 보통 그것들을 다음과 같이 명명했습니다.

다음 단계에서 dev를 사용하지 않으면 로컬 또는 개발자
병합 후 첫 번째 배포 인 경우 dev 또는 통합
테스트 또는 QA
3 단계에서 QA를 사용하지 않은 경우 uat 또는 수락 또는 QA
최종 사인 오프를위한 성능 단계 인 경우 사전 제작, 준비 또는 성능
찌르다

내 조언은 모든 제품 또는 프로젝트마다 각각의 이름을 입력하고 떠나는 이름, 목적 및 기준에 동의하는 것입니다. 그런 다음 7 번째 환경이 필요하거나 나중에 다른 이유로 5 가지만 필요하다는 것을 알게되면 다시 논의하십시오. 팀.

이름의 의미에 매달린 팀 구성원이있는 경우 항상 이름을 삭제하고 하나의 관리자를 통해 하나의 관리자에서 하나의 관리자에서 하나를 뺀 후 하나의 관리자에서 환경을 테스트하는 것을 거부하기 만하면 하나의 관리자에서 하나를 뺀 것입니다. 'QA'라는 이름이 아닌

서버 자체의 이름을 지정하려면 일반적으로 서버의 권한에 따라 이름을 지정하는 것이 좋습니다. 일반적으로 이것은 다음과 같습니다.

개발자 기계는 개발자 기계를 조작 할 수 있습니다
QA 머신은 개발자가 조작 할 수 없지만 프로덕션 지원을 통해 모니터링되지는 않습니다.
찌르다 기계는 찌르다 지원 사업

대부분의 사람들은 이러한 종류의 이름을 접두사 또는 접미사로 사용하여 "devsqllweb" "qasqlweb" "prodsqlweb"또는 이와 유사한 체인을 갖습니다.

— 계산서
소스

당신은 기본적으로 내가 온 결론을 말하고 있습니다. 본질적으로 임의의 표준을 설정하지 않고 상황을 해결할 수 있도록 일종의 표준이 있기를 바랐습니다. 내 문제는 "주요"환경 구조가 현재 진행중인이 프로젝트보다 적은 환경을 가지고 있다는 것입니다. (따라서 우리가 정상적으로 사용하는 것을 미러링 할 수는 없습니다.)-프로젝트에는 다양한 장소의 컨설턴트가 많이 있습니다. 하나는 동일한 표준을 가지고 있습니다. 이 질문을 몇 시간 더 열어두면 다른 사람이 들어올 지 알 수 있지만 이것이 제가 두려워하는 대답입니다.

— Marcus_33

나는 이것에 대한 표준을 보았다. 그것들은 불행히도 특정 상황에 대해 의견이 있거나 매우 구체적인 종류의 표준입니다.

— Bill

2

더 체계적이고 규제가 엄격한 산업에서 서버를 명명하는 옵션은 내가 가지고 있지 않은 사치라고 생각합니다. 서버는 회사 IT 정책에 따라 이름이 지정되므로 시스템의 실제 호스트 이름은 제어 할 수있는 것이 아닙니다.

우리가 한 일은 DNS 이름과 별칭의 경로입니다. 규칙은 첫 번째 문자로 개발 프로세스 (영역)에서 서버의 일반적인 역할을 나타냅니다.

p = 생산
d = 개발
s = 준비
t = 테스트

그런 다음 기계의 역할을 식별하기 위해 최대 3 글자 이름을 갖습니다.

앱 = 애플리케이션
db = 데이터베이스
웹 = 프론트 엔드 / 웹
kas = 캐싱

해당 영역에 여러 머신이있는 경우 숫자가 뒤 따릅니다. 우리는 이것을 내부 문서 서버에 게시하고 프로젝트와 부트 스트랩 단계에서 새로운 문서의 일부로 제공합니다.

개발 프로세스의 일부인 서버를위한 것입니다. 지원 기계의 경우보다 자유로운 정책이 있습니다. 새로운 보조 서버를 프로비저닝해야 할 때 개발 팀에 원하는 이름을 요청합니다.

이것은 흥미로운 것들로 이어졌고, 내가 가장 좋아하는 두 가지는 cerberus (내부 프록시) 상자와 hades (문서 서버 / 인트라넷)입니다.

이것이 최선의 방법은 아니지만 이것이 우리가 사용하는 것이며 우리에게 효과적입니다.

— 부한 칼리드
소스

1

고정 된 정의가 없습니다. 일반적인 관행에서 사용하는 몇 가지가 있습니다 (목록에 나와 있음). 토이 스토리에서 각 환경에 캐릭터 이름을 부여하려면 권장하지는 않습니다.

내가 할 일은 회사의 용어집을 만드는 것인데, 우리가 사용하고 싶은 이름을 줄 것입니다.

— 미야모토 아키라
소스