DevOps와 소프트웨어 구성 관리의 차이점

개발 운영과 소프트웨어 구성 관리의 차이점은 무엇입니까?

저에게는 DevOps와 Software Configuration Management가 다음에 중점을 둔다면 같은 것 같습니다.

1. 구축 개발 인프라 - 버전을 담당하고있는 관리, 빌드 관리, 배포 관리, 의존성 관리, 지속적인 통합 및 전달 등
2. 개발자 환경 구성을위한 모범 사례 사용 .
3. 개발 프로세스의 품질 보증 -개발 효과의 메트릭 수집, 개발 프로세스의 병목 현상 제거 작업 (단위 테스트 실행, 단위 테스트 적용 범위 평가, 검사 실행 등)
4. 인프라 관리 -대상 플랫폼 및 해당 사양.
5. 릴리스 관리 -릴리스가 제 시간에 고객 / 클라이언트에게 전달되었는지 확인하십시오.

어쩌면 내가 뭔가를 놓치고 있습니까? 이 링크 는 'Software Configuration Management'라는 용어가 널리 사용됨을 보여줍니다. 그러나 여전히 나열된 활동 범위를 설명하기 위해 어떤 단어 조합을 사용 하시겠습니까 : 개발 운영 또는 소프트웨어 구성 관리 ?

이 용어는 매우 유사한 개념과 책임을 설명 하며 일반적 으로 다소 동의어입니다. "DevOps"라는 용어는 Devopsdays Ghent 2009 컨퍼런스 및 후속 Devopsdays 이벤트에 의해 대중화되는 비교적 새로운 것 입니다. 이 다이어그램 에서 가장 잘 설명됩니다 .

반면에, 소프트웨어 구성 관리는 전문직에서 훨씬 더 확립 된 용어이며 소프트웨어 이외의 용어 인 구성 관리 에서 파생됩니다 . 소프트웨어 구성 관리는 종종 소프트웨어 엔지니어링 컨텍스트에서 참조되며, Roger Pressman은 "소프트웨어 엔지니어링 : 실무자의 접근 방식"에 간단한 정의를 제공합니다 .

변경 될 수있는 작업 제품을 식별하고 이들 간의 관계를 설정하고 이러한 작업 제품의 다른 버전을 관리하기위한 메커니즘을 정의하고 부과 된 변경을 제어하고 변경 사항을 감사 및보고함으로써 변경을 제어하도록 설계된 일련의 활동입니다.

참조하는 모든 용어가 모호하지만 DevOps는 소프트웨어 개발자의 관점에서 볼 때 특히 밀접하게 연결된 팀을 우선시 하는 Configuration Management 또는 Software Configuration Management와 거의 동일한 원칙을 설명하는 덜 공식적인 방법 인 것 같습니다 .

DevOps는 전통적으로 개발 활동으로 간주되는 것과 운영 활동으로 간주되는 것 사이에 연결이 끊어 졌다는 인식이 높아지고 있다는 반응입니다. 이러한 단절은 종종 갈등과 비효율로 나타납니다.

같은 기사에서 SCM과의 유사점에 주목하십시오.

혼란과 장벽을 추가하는 것은 개발 및 운영 툴링에서 너무 일반적으로 일치하지 않습니다. 개발자가 매일 요청하고 사용하는 인기있는 도구를 살펴보십시오. 그런 다음 시스템 관리자가 매일 요청하고 사용하는 인기있는 도구를 살펴보십시오. 버그 추적기 및 SCM과 같은 몇 가지 눈에 띄는 예외가 있지만 서로 도구를 사용하거나 도구 사이의 상당한 통합에 관심이있을 것입니다. 도구 유형에 겹치는 부분이 있더라도 각 그룹마다 구현이 다를 수 있습니다.

용어의 사용법에 관해서는 비교가 실제로 의미가 없습니다.

1. SCM은 경쟁 용어가 아닌 CM의 하위 집합입니다.
2. DevOps는 상당히 새로운 용어이며 기존 용어와 비교할 때 아무런 의미가 없습니다.
3. DevOps는 개발자 작업에서 파생되지만 (확실히) 확장되지는 않습니다.

개인적으로 몇 년 동안 Sr. Software Configuration Manager가되었습니다 (10+). 다양한 실제 상황에서 용어가 일치하지 않는다고 들었습니다. 직책의 상대적 특성으로 인해 비 기술적 인 직원에게는 드문 일이 아닙니다. 둘 다 비슷한 역할, 요구 및 요구 사항을 가지고 있지만 내 의견으로는 명확하게 나눌 수 있습니다.

이러한 역할의 구분을 설명하는 가장 좋은 방법은 상호 작용에 대한 상대성에 초점을 맞추는 것입니다. 이를 위해 Software Configuration Management는 소스 코드의 통합, 배포, 릴리스 및 관리와 함께 내부 시스템 및 환경에 중점을 둡니다. 개발자 운영 (DevOps)은 외부에서 사용되는 응용 프로그램 아키텍처의 운영 측면에 더 중점을 두면서 사용 및 환경 실행을위한 코드를 명확하게 이해합니다. 기계 성능이 저하의 징후를 보이면, 여러 응용 프로그램 간의 통신에 결함이 있거나, BtB (Business to Business) 통신 및 / 또는 프로덕션 환경과 관련된 아키텍처 제한 사항이있는 경우 진단을 위해 개발자 오퍼레이션을 찾고 해결책.

일반적으로 필자가 경험 한 바에 따르면 Software Configuration Manager는 이러한 작업도 수행 할 수 있지만 환경 구성 및 소프트웨어 개정의 추적, 관리 및 배포라는 핵심 목표에서 벗어납니다. 업무 분리, 버그 및 결함 추적, 프로젝트 추적, 소프트웨어 개발 수명주기 및 웜 플로우를 허용하는 소프트웨어 관리 이러한 작업은 개발자 작업의 핵심이 아니므로 덜 중요하지만 여전히 수행 할 수 있습니다.

나는 각각의 혼란의 많은 사례를 보았고, 각각에는 약간의 교차가 있습니다. 그러나 각 주요 직책과 관련하여 각 독립적 인 직책의 책임 간의 차이를 생각하는 것이 가장 중요합니다. 기본적으로 내부 구성 시스템 및 하드웨어를 처리하여 환경 구성 및 제품 릴리스를 관리 할 때 Software Configuration Manager를 찾아야합니다. 반면, 고객이 사용하는 시스템의 시스템 성능, 모니터링, 연구 및 진단을 처리 할 때는 개발자 운영 또는 DevOps를 참조하십시오.

이제 이것은 진창이나 결정적인 대답이 아니라 각 직책의 차이점을 개인적으로 식별하는 것이 아닙니다. 나는 기본이 아닌지, 또는이 대답으로 상황이 더 분명한지 알고 싶습니다.

DevOps에 대한 확실한 정의를 찾기가 어렵습니다. 해야 할 일보다 더 많은 아이디어입니다. 그리고 모든 사람들이 그것이 의미하는 바에 정확히 동의하는 것은 너무 새로운 아이디어입니다. 그럼에도 불구하고 여기에 내 취향이 있습니다.

DevOps는 실제로 구성 관리의 새로운 용어이지만 역할이 1 인 역할이 아니라 개발 팀과 운영 팀 간의 공동 작업임을 보여주기 위해 선택되었습니다.

역사적으로, 구성 관리는 개발 팀에 의해서만 수행 된 다음 모든 것을 의심하는 운영으로 전달되었습니다. 솔직히 말해서 충분히 공평합니다. 그들은 책임이 있습니다. 오전 4시에 잘못되었을 때 처음으로 전화를받습니다. 그들은 실제로 개발에 참여해야합니다.

이것은 문제에 대한 간단한 설명입니다. DevOps는 개발 (개발 환경에서 프로그램 코드 개발)과 운영 (생산 환경의 최대 가동 시간 보장) 간의 조정 또는 관계를 설명하는 데 사용되는 용어입니다.

소프트웨어 구성 관리는 이러한 조정을 달성하는 수단입니다. SCM에는 개발에서 생산 (운영)으로 전환하는 프로세스의 자동화를 관리하기위한 도구 및 기술이 포함되었습니다.

요약하면 SCM은 Dev와 Ops를 연결합니다.

DEVOP는 운영 자동화 끝에 있습니다-배포 자동화 스크립트, 환경 구축, 그런 종류의 것들. 반면 SCM은 제품 무결성과 제품 변경의 효과적인 관리 및 추적 가능성에 관한 것입니다. 저는 항상 ALM을 SCM의 일부로 간주했습니다. 결국 변경의 동인이 누구인지 또는 누가 변경했는지 알지 못하면 제품 변경 사항을 지구상에서 어떻게 관리 할 수 ​​있습니까? 배포 프레임 워크는 어느 쪽이든 떨어질 수 있으며, 어느 쪽이 작업을 수행해야하는 조직의 규제 요구에 따라 결정될 수 있습니다. 결국 개발자가 빠른 해킹을 수행하여 투석기 만 제대로 작동한다는 의미입니다. 99.99 % 개발자가 IP 주소를 하드 코딩 했으므로 웹 사이트 코드를 해킹 할 수있는 상황이 필요합니까?