생산을 정확히 정의하는 것은 무엇입니까?

https://stackoverflow.com/questions/490289

20-08-2019
|

문제

한동안 프로그래밍을해온 거의 모든 사람과 마찬가지로 저는 "생산 코드"라는 용어에 익숙하며 그 의미에 대한 모호한 감각을 가지고 있습니다. 그러나 Wikipedia와 Google이 할 수없는 것처럼 보이기 때문에 누군가가 반 강력한 정의를 제공 할 수 있습니까? 소수의 사람들이 사용하는 내부 도구와 같은 내부 도구와 같이 제작으로 간주되는 많은 회색 영역이있는 것 같습니다. 완전하고 합리적으로 버그가없고 작동하지만 광택, UI 및 광범위한 테스트가 부족합니다.

해결책

생산은 안정적으로 일관되게 작업 해야하는 모든 것을 의미합니다.

빌드 스크립트이든 공개 웹 서버이든.

다른 사람들이 귀하의 코드에 의존 할 때, 특히 그것을 이해하지 못하는 사람들 (예 : "스마트"개발자이지만 그룹에는 없지만 쓴 라이브러리를 사용하는 사람들도 있습니다). 해당 코드는 프로덕션 코드입니다.

생산 코드가 실패하면 "작업 중지"및 "돈이 손실되기"때문에 생산입니다.

다른 팁

코드가 프로덕션 시스템에서 실행되면 실제 상황에서 의도 된 잠재 고객이 사용하고 있음을 의미합니다.

그러나 생산 코드가 반드시 강력하고 신뢰할 수 있거나 안정적인 코드를 의미하지는 않습니다. 매일 WTF 이와 관련하여 많은 증거를 제공합니다.

내가 이해하는 정의는 생산 코드가 실시간 비 테스트 베드 시스템에 설치되거나 사용되는 코드라는 것입니다. 회사에 내부적으로 사용되는 서버는 회사 직원이 사용하는 라이브 시스템 인 경우 생산 시스템입니다. 여기서 요점은 코드를 작성하는 회사 내부 서버에서 실행되는 코드가 프로덕션 코드 일 수 있다는 것입니다.

일반적으로 내부 코드를 볼 때 좋은 차이점은 코드를 유지하는 그룹이 코드를 사용하여 그룹과 분리되어 있는지 여부입니다. 그룹이 별도 인 경우 코드는 프로덕션 코드 일 것입니다. 비즈니스를 실행하는 경우 코드에 따라 다르면 사내에서 개발되고 유지 되더라도 생산 코드입니다.

편집 : 짧은 답변 : "농장을 베팅하는 경우" "생산".

이것은 위대한 질문입니다. 오해로 인해 모든 사람이 일상적으로 모든 사람이 문제를 일으키는 절대적으로 비판적인 구별입니다. 무엇인지에 대한 질문 "생산"무엇이 무엇인지에 대한 관련 질문의 하위 집합입니다."환경".

그래서 대답의 일부는 "생산"입니다"환경"그게 대부분입니다 중요하며 가장 신뢰합니다.진짜" 물건.

이제 우리는 정의해야합니다.환경"(그리고 다시 방문하십시오”생산"). 우리는 여전히 만족스러운 대답과는 거리가 멀다.

우리는 프로그래머가 용어를 사용합니다.환경"소프트웨어를 실행하는 하드웨어로 구성된 컴퓨터 시스템을 지속적으로 언급합니다. 소프트웨어는 우리가 다른 소프트웨어에 의존하는 소프트웨어와 다른 소프트웨어가 작성한 코드입니다. 우리는 코드를 작성하고 다른 소프트웨어와 통합 한 다음, 우리는 우리를 통합합니다. 일반적으로 의도 한 전체 방식으로 통합 소프트웨어를 실행할 때까지 에스컬레이션 된 일련의 테스트 (단위 테스트, 통합 테스트, 기능 테스트, 수락 테스트, 회귀 테스트 등)를 통해 통합 소프트웨어를 실행합니다.

물론 모든 것이 완전히 자동화되는 것은 아닙니다. 일반적으로 수많은 사람들이 참여하고 있으며 수행 할 수동 프로세스가 있습니다. 우리는 프로그래머가 가능한 많은 프로세스를 자동화 할 수있는 방법을 찾고 있지만, 우리가 작업하는 시스템에는 항상 "사람/기계 경계"가 있습니다. 종종 특정한 경우에는 그러한 경계가 많이 있습니다.

반면에, 상당한 자동화가 전혀 없을 수 있습니다. 예를 들어, 우리는 "생산"우리가 매뉴얼 노동을하는 사람들로 가득 찬 방을 가졌을 때 제작 ㅏ 제품. 따라서 우리에게는 자동화가있을 필요가 없습니다. "생산" "환경". 중간지면이 있으며, 관련 자동화에는 천을 직조하기 위해 직기를 달리는 사람의 경우와 같이 소프트웨어가 포함되지 않습니다.

또한 없을 수도 있습니다 제품, 우리는 우리의 언어를 "" "" "" "" "" "" ""과생산" "환경"제품이없는 서비스 제공 업체를 포함합니다.

마찬가지로, 테스트에는 소프트웨어가 포함되지 않을 수 있습니다. 소프트웨어 중심의 시스템 (예 : 직기) 또는 사람 (교육 및 평가)을 테스트 할 수 있기 때문입니다.

이제 우리는 "의 모든 중요한 요소를 만졌다"환경":

목적이 있습니다 intent, 추구 당하고 있습니다
an intent 인수가 필요하므로 a가 있어야합니다 sponsor (기계는 없지만 기계가 아닌) intent
저것 intent 다양한 것을 통해 추구됩니다 processes 그것은 다양한에 의해 수행됩니다 actors
저것들 actors 사람 일 수도 있고 하드웨어에서 소프트웨어 실행이거나 소프트웨어 중심의 기계 일 수 있으므로 자동화가있을 수도 있고 없을 수도 있습니다.

이제 우리는 원래 용어를 올바르게 정의 할 수 있습니다.

an environment 모든 것으로 구성됩니다 processes 그리고 그들의 actors 그것은 특정한 것을 추구하기 위해 협력합니다 intent 그것을 대신하여 sponsor. 이는 하드웨어에서 소프트웨어를 실행하는 것을 의미합니다. 즉, 소프트웨어 중심의 기계를 의미하며 이는 사람들이 다양한 업무를 수행하는 것을 의미합니다. 그것은 intent 주로 정의합니다 environment, 그것의 것이 아닙니다 processes 또는 그 actors.

뿐만 아니라...

만약 intent 특정에서 추구되고 있습니다 environment 입니다 sponsor's 일반적으로 생산을 포함하는 궁극적 인 목표 product 또는 제공 a service 돈을 대가로, 우리는 그것을 말합니다. environment ~처럼 production.

이제 우리는 조금 더 나아갈 수 있습니다.

만약 intent 에서 추구되고 있습니다 environment 의 검증입니다 processes 그리고 그들의 actors 준비 중 production, 우리는 그것을 a라고 부릅니다 test environment.

우리는 더 그것을 an이라고 부릅니다 integration environment 해당 테스트에 상당한 개인 또는 그룹의 초기 가입이 포함 된 경우 processes 그리고 그들의 actors.

그 준비가 인간의 "프로그래밍"과 관련이 있다면 actors 새로운 공연 processes, 또는 후속 검증 (평가)은이를 training environment.

이러한 차이와 정의로 무장 한 우리는 이제 몇 가지 일반적인 시나리오를 이해할 수 있습니다.

an environment 일치하지 않는 이름으로 잘못 표지 될 수 있습니다. intent, 예를 들어 a training 환경이 사용됩니다 test.

an environment 언제와 같이 심하게 오용 할 수 있습니다 integration 또는 training 완료되었습니다 production.

an environment KEY와 같이 허위 진술을 할 수 있습니다 processes 또는 actors 미확인 (예 : 수동 조정 또는 사람들을 완전히 무시함으로써).

an environment 리포지션을 통해 리실로 묶을 수 있습니다 processes 그리고 actors 새로운 intent. 일부 조직의 매우 성공적인 기술은 일상적으로 여러 세트의 "플립"입니다. actors (서버 호스팅 소프트웨어)간에 production, test, training, 그리고 integration 각 릴리스시.

대부분의 경우 단일 actor (사람 또는 하드웨어)는 여러 가지를 실행할 수 있습니다 processes 다중에 참여할 수 있습니다 environments. 예를 들어, 단일 컴퓨터 서버는 수행하는 소프트웨어를 호스팅 할 수 있습니다. production 수행하는 다른 소프트웨어를 호스팅하면서 트랜잭션 test 또는 training 기능.

일반적으로 단일 인스턴스 actor 하나만 참여해야합니다 environment 한 번에. 매우 드문 경우에는 단일입니다 actor 공유 할 수 있습니다 environments 만약 intents 상호 호환됩니다. 대부분의 경우, 그러한 공유를 시도하는 것은 매우 현명하지 않습니다. intents 실제로 호환되지 않습니다. 완벽한 예는 a test process 지원하는 서버에서 production processes, 가동 중지 시간이 발생합니다 test 전체 서버가 실패했습니다.

따라서, intent 의 environment 다음과 같은 개념을 포함하도록 매우 넓은 위도로 해석되어야합니다. 유효성, 신뢰할 수 있음, 성능, 재해 복구, 정확성, 정도, 반복성, 장수, 이것은 등을 의미합니다 actors 그리고 processes 종종 등을 포함하도록 해석되어야합니다 힘 제공, 냉각, 백업, 그리고 중복성.

마지막으로 상황은 상당히 복잡해 질 수 있습니다. 예를 들어 데스크탑 컴퓨터 (actor) 개발 팀이 임무를 수행 할 수 있습니다 (sponsor) 소스 컨트롤을 호스팅하기 위해 (process), 팀이 주요 직업에 의존하는 (production). 그럼에도 불구하고 IT 직원은 동일한 데스크탑 컴퓨터를 단순히 개발자 워크 스테이션과 본다 (development, 아니다 production) 그리고 하드웨어 문제를 일으킬 때 경멸과 비 균형으로 취급합니다. 그러나 개발자들은 생산하고 있습니다 production 코드, 그래서 그들은 또한 일부가 아닙니다 production? 관점이 중요합니다.

편집 : 생산 품질

견고한 검증 (testing) 방법론은 포장 코드를 가져와야합니다 development 그리고 일련의 일련의 것을 통해 실행하십시오 tests (통합, TQA, 기능, 회귀, 수락 등) 다른 쪽에서 나올 때까지 production 사용. 그러나 그것은 패키지를 만듭니다 production 품질, 그러나 실제로는 아닙니다 production. 패키지는 만됩니다 production A. sponsor 실제로 배치합니다 environment 그 궁극적 인 수준으로 intent.

그러나 귀하의 조직이 단지 해당 패키지를 생산하는 경우 product) 다른 사람의 소비를 위해, 그러한 릴리스는 production 그 조직은 이와 관련하여 경험할 것입니다 product, 따라서 용어를 늘리는 것이 일반적입니다 production 그것을 명확히하기보다는 적용합니다 production 품질. 실제로, 그 조직은 production 환경은 actors 그리고 processes 그 결과 개발/릴리스 노력에 관여합니다. product.

나는 그것이 꽤 복잡해질 수 있다고 말했다 ...

의도 된 사용자베이스에서 사용하는 모든 코드는 '프로덕션 코드'에 대한 내 정의에 적합합니다.

물론, 그 정의의 회색 영역은 사용자베이스가 누구인지 명확하게 정의하는 것입니다.

G-Man

생산 소프트웨어는 서비스 중단 또는 저하없이 필요한 워크로드에서 수행 할 수 있습니다.
소프트웨어는 다양한 생산 시나리오에서 성공적으로 테스트되었습니다
실제 비즈니스, 즉 생산 환경, 시간, 코드 리팩토링 및 세부 사항에 대한 관심
생산 코드는 허용 가능한 수준의 유지 보수성을 가지고 있으며 합리적으로 잘 댓글을 달고 있습니다.
문서 매뉴얼은 기능, 모든 기능을 설명하고 유지 보수를 용이하게합니다.
생산 소프트웨어가 국제 서비스 또는 응용 프로그램 인 경우 현지화해야합니다.
생산 코드는 최종 사용자가 사용하며, 종종 서비스 용어 계약에 설명 된 조건에 따라 고객
프로덕션 소프트웨어가 반드시 안정적인 미션 크리티컬 소프트웨어를 의미하는 것은 아닙니다.
소프트웨어는 잘합니다.
로그 파일은 런타임 성능 및 소프트웨어 신뢰성 지표 및 디버깅 및 소프트웨어 유지 관리 가능성을 용이하게하는보고에 대한 정확한 설명을 제공합니다.

이를 설명하는 가장 좋은 방법은 "Leads-to"배포 및 "후속 조치"배포 코드라고 생각합니다. 배포 자체는 소프트웨어 시스템을 사용할 수 있도록하는 모든 활동으로 정의됩니다. 사람들이 사내 또는 다른 방식으로 코드를 사용할 준비가 된 경우 프로덕션 코드입니다.

간단한 말로 "의도 된 청중이 살고 사용하는 생산 코드"

"생산 코드"라는 용어는 두 가지 다른 개념을 혼합합니다. 하나는 배포 관리이고 다른 하나는입니다 수명주기 릴리스.

단어의 엄격한 의미에서, 시스템은 비즈니스 또는 서비스 운영의 일부로 사용될 때 생산 중입니다. 생산에없는 것은 개발, 테스트, QA, 데모 및 스테이징 시스템입니다. 생산 시스템은 즉시 품질을 암시하지 않습니다.

릴리스 라이프 사이클의 관점에서 "프로덕션"빌드는 일반 대중 또는 고객에게 출시되는 빌드입니다. 사전 알파, 알파, 베타, (기능 완료, 코드 완료 등) 및 릴리스 후보자 후 단계입니다. 업데이트를 쉽게 배포 할 수없는 수축 랩 제품의 경우 생산 단계에 도달하면 일련의 테스트 및 버그 수정이 있음을 의미합니다.

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

제휴하지 않습니다 StackOverflow