DevOps는 이제 개발자가 인프라 및 릴리스에 대한 책임을진다는 것을 의미합니다. 그러나이 변경의 원인은 무엇입니까?

DevOps는 이제 개발자가 인프라 및 릴리스에 대한 책임을진다는 것을 의미합니다. 그러나이 변경의 원인은 무엇입니까?

나는 카드를 테이블 위에 놓을 것이다. 나는 개발자이고 "DevOps"와 비 문화에서 일했다. 인프라 및 릴리스, QA 및 관련 행사에 대해 걱정해야하는 것은 좋은 코드를 작성하는 데 큰 방해가됩니다.

그러나 업계는이 방향으로 나아가고 있는데, 그 이유는 무엇입니까? "역할"의 역할 전문화 모델은 어떤 문제를 일으켰습니까?

주된 이유는 클라우드입니다.

예전에는 코드를 플로피 디스크에 넣은 다음 CD로 배송 한 다음 서버에 배포 한 다음 두 서버에 복원 (복원성을 위해)했습니다. 그 배포는 모두 수동으로 수행 할 수있었습니다. 인간에 의해, 그래서 인간은 그것을하는 훈련을 받았습니다.

오늘날 귀하의 코드는 종종 수십 또는 수백 대의 서버로 연결됩니다. 이러한 서버에 대한 프로비저닝, 구성 및 배포는 사람이 수동으로 수행 할 수 없습니다. 이제 Chef 나 그 친족을 사용하고 있기 때문에 해당 프로세스를 자동화 할 수있는 충분한 스크립팅을 알기 위해서는 시스템 관리자가 필요합니다. 그러나 솔직히 말해서이를 수행 할 수있는 시스템 관리자는 충분하지 않았습니다. 그래서 슬랙을 해결하기 위해 개발자들이 끌어 들였습니다.

그렇습니다. 점점 늘어나는 개발자의 요구 사항에 더 많은 기술을 추가하면 자연스럽게 다른 곳에서도 역량이 줄어들 것입니다. 아이디어 빌드 / 릴리스 프로세스에 dev에 대한 통찰력을 허용, 더 나은 문제를 예상하거나 개선 할 수있는 자율성을 가질 수 있다는 것입니다. 아이디어는 릴리스 승리가 코드 작성 손실을 능가하기 때문에 모든 품질이 향상된다는 것입니다.

나는 사람들이 원하는만큼 트레이드 오프가 가치가 있다고 회의적이다.

여러 조직이 DevOps로 전환해야하는 이유는 여러 가지가 있습니다.
나는 자주 나오는 것들을 나열하려고 노력할 것이다.

변경 시간 단축주기 변경
요청과 실제로 조직에서 배포 및 사용되는 것 사이에는 시간이 오래 걸립니다. 먼저 개발자가 개발주기 중 하나를 계획하고 제공 한 후 릴리스주기 중 하나를 계획합니다. 두 사이클 모두 테스트를 포함하며 문제가 발견되면 두 사이클이 모두 재설정됩니다. 개발 및 운영 부서를 통합함으로써 두 프로세스를 합리화 할 수 있습니다.

소프트웨어와 하드웨어 문제
버그와 대피가 오리 시즌인지 토끼 시즌인지 논쟁하는 버그 버니 만화를 기억하십니까? 이제 개발자가 하드웨어 문제라고 주장하고 작업이 소프트웨어 문제라고 주장하는 개발자 및 운영 부서와 함께했다고 상상해보십시오. 최종 사용자에게는 차이가없는 구별입니다. 그들은 단지 그것을 고치기를 원합니다.
개발자와 운영을한데 모아 문제를 해결해야합니다. 소프트웨어 및 하드웨어 문제 일 수도 있습니다.

우리와 그들 모두 개발자와 운영 부서간에 유사한 일이 필요합니다. 필드가 성숙하고 프로세스가 공식화되고 표준화 될수록 이들 부서 사이의 거리가 멀어지고 있기 때문입니다. 따라서 전통적인 모델의 문제점 중 하나는 개발자와 운영 모두에게 "우리"와 "그들"처럼 보인다는 것입니다. 둘 다 상대방의 책임의 어려움을 완전히 이해하지 못합니다.
사이 많은 회사에서 테스터와 개발자 사이의 거리가 멀어지면서 부서가 분리되고 개발주기가 점점 더 공식화되고 표준화되었습니다.
애자일이 등장함에 따라 개발자와 테스터는 서로 긴밀히 협력 해 왔으며 개발주기에 대한 서로의 관점을보기 시작했으며 심지어이를 존중하게 될 수도 있습니다.

기대 / 장점
DevOps를 통해 두 전문 분야는 전통적으로 다른 기술에 의해 수행 된 기술 중 일부를 배웁니다. 아무도 시스템 관리자가 소프트웨어 엔지니어가되거나 개발자가 네트워크 엔지니어가 되리라고 기대하지는 않지만 둘 다 상대방의 책임을 맡을 것으로 예상됩니다. 이것은 당신이 정말로 여분의 손이 필요할 때 거기에 있음을 의미합니다.

또한 개발자에게는 확실한 단점이 있습니다. 이제 테스트 환경을보다 강력하게 제어 할 수 있으며 소프트웨어를 사용자에게 배포하고 조직 내 더 많은 사람들이 공예에 대한 사랑을 공유 할 수 있습니다.

품질 코드를 작성하는 것만으로는 충분하지 않습니다. 당신은 문제의 일부이거나 해결책의 일부입니다.

많은 프로그래머들에게 일부 최종 사용자가 지불하는 소프트웨어를 작성하고 있습니다. 양질의 코드를 작성하는 것은 좋은 일이지만, 고객 / 관리자가 항상 항상하고 빠르게해야한다고 가정하는 것입니다. 목수가 보드를 정확하게 자르는 것과 비슷하지만 실제로 누군가가 지불하고 싶은 것을 만들고 있습니까?

개발자는 DevOps를 사용하여 개발자가 코드를 최종 제어 할 수 있도록 더 많은 제어 권한을 갖게되고 희망을 갖게됩니다. 운영 프로세스를 자동화하는 데 가장 적합한 사람은 누구입니까? 최종 사용자 만족은 주요 측정 스틱입니다. 품질 코드를 작성해야 할뿐만 아니라 고객을 만족시켜야합니다. 죄송하지만 아무도 코드를 다시 사용하지 않습니다. 일반 주택 구매자가 나무를 자르고 자신의 보드를 만들 었는지 신경 쓰지 않는 것처럼 ORM 프레임 워크를 처음부터 새로 작성해도 상관 없습니다. "업그레이드"가 기본값으로 다시 설정되어 있기 때문에 모든 구성 파일을 다시 실행하고 싶습니까?

개발자 찹을 과시하고 싶습니까? 사람들이 사고 싶어하고 전체 사용자 경험을 포함하는 무언가를 만드십시오. 양질의 코드를 작성하는 것이 좋지만 불행히도 유료 고객의 만족도에 공개되지 않으면 보너스를받지 못할 수 있습니다. QA를 탓해도되지만, 회사에 아직 더 많은 돈을 지불 할 여유가 없습니다.

Agile & Scrum과 손을 잡은 것입니다. 더 이상 명확하게 정의 된 직무 역할이 없습니다. 모두는 "개발자"입니다.

그리고 그것은 단지 작전이 아닙니다. 개발자는 종종 비즈니스 분석, 테스트, 데이터베이스 관리 및 빌드 관리자 역할을 수행해야합니다.

문제의 핵심은 churn 이라고 부르는 것 입니다. 프로젝트에 관련된 다양한 역할의 수가 증가함에 따라 더 많은 회의, 오해 및 리소스 충돌이 발생했습니다. 사용자들에게 소프트웨어를 신속하게 제공하는 것은 최종 게임이며 그 길을 다소 벗어날 수있는 모든 것입니다.

이것은 완전히 나쁜 것은 아닙니다. 잼이 매우 심해지더라도 평범한 개발자가 기술을 확장합니다. 얇아 지 . 또한 배포가 방해 될 때 문제가있는 위치에 대한 코더와 서버 관리자 간의 논쟁을 이끌고 있습니다. 개발자는 종종 최첨단 기술을 사용하여 솔루션을 제공하기를 원하며 서버 관리자는 설치 세트가 제공 될 때까지 관리자 POV에서 이것이 무엇을 의미하는지 종종 모릅니다.

더 밝고 진보적 인 사고 회사들은 마침내 T 자형 사람들 이 좋은 것이라는 것을 깨닫기 시작했습니다 . 그러나 그들이 좋은 것이라고 생각 하고 전통 문화가 이전에 채택 된 곳에서 마술처럼 일어날 것으로 기대하는 것에는 차이가 있습니다.

나는 확실히 그 이상의 개발자를위한 몇 가지 좋은 이유보다가 있어요 또한 운영 및 품질 관리 (때로는) 관리 할 수 있습니다. 다음은 그중 세 가지입니다.

• 관심사
  일부 개발자는 실제로 제품의 모든 측면에서 작업 하기 를 원합니다 . 그들이 잘하고 팀에 공허를 채우거나 다른 역할을하는 기존 팀원들에게 좋은 지원을 제공한다면 그들을 막을 이유가 없을 것입니다.
• 비용
  대기업은 전문 인력을 감당할 수 있습니다. 소규모 회사는 때때로 할 수 없습니다. 이러한 장소 중 일부는 단순히 물건을 집 밖으로 가져와야하는 1 명 또는 2 명 또는 3 명의 개발자를 고용 할 수 있습니다 .
• 프로젝트 규모
  모든 프로젝트가 다 인간 프로젝트 인 것은 아닙니다. "작은"응용 프로그램을 작성하는 경우 한 사람 이상이 작업을 완료하도록하는 것이 과도 할 수 있습니다. 또한 특정 역할을 수행하는 개인이 많은 소규모 프로젝트는 무섭습니다 . 아무도 할 수있는 충분한 일이 없다 - 당신이 할 경우에도 여유가 그들에게 6 개월간 자신의 엄지 손가락을 만지작 거릴 모든 주위를 유지하기 위해, 좋은 것들은 유지되지 않습니다. 그들이 지루하지 않으면, 그들은 두려워하거나, 당신은 당신이 아무것도 대가를 지불하고 있음을 알게 될 것입니다. 어느 쪽이든, 좋은 직원은 떠나고 모든 사람이 당신에게서 멀어 지도록 할 것입니다.

... 그리고 다른 이유들도 확실합니다.

"인프라 및 릴리스와 QA 및 관련 행사에 대해 걱정하고있는 것은 좋은 코드를 작성하는 데 큰 방해가됩니다."

DevOps는 인프라와 릴리스에 대한 걱정과 QA가 좋은 코드를 작성하고 있다고 생각합니다.

비 DevOps 문화에서 작동하는 이전의 역할에서 필자는 DevOps 문화가 막을 수 있었던 많은 문제를 겪었습니다. 비 대표적 플랫폼에서 개발 된 코드, 개발자가 클라이언트가 사용한 문자 인코딩에 대해 무지한 문자 인코딩 문제, 약간의 추측없이 Ops 팀에 대해 수동 코딩되고 불충분 한 배포 지침과 관련된 성능 문제 -작업.

이제 Dev와 Ops 측면 모두에서 전문화가 증가하면 이러한 일부를 극복 할 수 있지만 팀간에 지식과 작업을 공유하여 많은 부분을 해결할 수 있다고 주장 할 수 있습니다.

DevOps는 "Dev now do Ops"를 의미 할 필요는 없습니다. 원래이 용어는 "Dev 와 Ops 사람들이 한 팀에서 긴밀하게 협력합니다 "라는 의미 였습니다. 그것은 않습니다 일을 자동화하는 프로그램의 일종을 필요로하기 때문에 옵스 사람들이 더 많은 개발진처럼 될 필요가 있고, 기존의 수동 방법은 그것을 잘라 (이 시점에 더 자세한 정교에 대한 다른 답변을 참조)하지 않는 것을 의미한다.

에서 위키 백과 :

DevOps (잘려진 개발 및 운영)는 소프트웨어 제공 및 인프라 변경 프로세스를 자동화하면서 소프트웨어 개발자 및 기타 IT (Information-Technology) 전문가의 협업 및 커뮤니케이션을 강조하는 문화, 운동 또는 실습입니다.

따라서 필자가 실제로 개발자로서 동일한 이전 책임 과 추가로 현재 운영 책임을 가지고 있다면 관리 부분에서 잘못 계산 된 것 같습니다. 사물을 자동화하면 운영 인력이 줄어들어 실제로 비용을 절감 할 수 있습니다. 그러나 DevOps는 "모든 Ops 직원을 제거하고 Devs가 추가 작업을하도록하자"는 의미는 아닙니다.

Buzzwords와 마찬가지로 자주 시맨틱 확산이 발생하고 갑자기 사람들이 "개발자를 운영하게하고 돈을 절약 할 수있을 것 같습니다 ..."라고 생각합니다.