DevOps는 SaaS 제품을 보유한 회사로 제한됩니까?

지속적인 제공, 자동화 등과 같은 DevOps를 설명하는 관행은 SaaS 제품과 같은 지속적인 서비스를 제공하는 제품과 관련이 있습니다.

예를 들어, 주로 다른 고객을 위해 프로젝트를 수행하는 소프트웨어 개발 회사는 프로젝트가 끝난 후에도이를 유지하지 못할 수 있습니다. 그리고 클라이언트 프로젝트는 관련이 없기 때문에 다른 클라이언트와 공유되지 않습니다.

DevOps는 일회성 인 여러 프로젝트를 개발하는 회사에도 적용됩니까? 이 경우 어떤 DevOps 사례가 적용됩니까?

절대적으로하지!

DevOps는보다 효율적인 효율성을 위해 기존 사일로 (부서)를 분해하는 것입니다.

팀 간의 의사 소통 개선, 가시성 향상 및 신뢰성 있고 자동화 된 프로세스는 더 나은 제품을 달성하는 방법입니다.

나는 내부 도구를 지원하고 대중을 대상으로하는 웹 사이트를 개발할 수있는 큰 미디어 회사에서 일했습니다.

우리의 경우 DevOps의 이점은 다음과 같습니다.

• 지속적인 빌드를 통해 코드에 통합 또는 빌드 문제가있는 경우 나중에 개발 팀에 알리지 않습니다. 그들은 방금 저지른 코드 조각에 마음이있는 동안 문제를 해결할 수 있습니다.
• QA 팀은 지속적인 테스트 및 제공을 통해 문제를 조기에 발견하고 더 일찍보고 할 수있었습니다. 이로 인해 버그를 찾고 수정하는 데 걸리는 시간이 줄어들고 이러한 조사의 복잡성이 줄었습니다.
• 우리는 로그 수집 및 집계 도구를 사용하여 개발자가 일반적으로 보지 않을 것 (디버거에 매우 열중했습니다)에 액세스 할 수 있도록했습니다-다른 팀이 로그를보고 사용하는 방법을 이해하여 전반적인 로그 품질을 향상시킵니다.
• 우리는 종종 정보를 공유하고 팀간에 지식을 공유하기 위해 문서를 작성하여 벽을 허 물었습니다. Ops의 요구 사항을 이해함으로써 애플리케이션을 부트 스트랩 할 때 항상 염두에 두어야 할 사항 (속성 관리 위치 / 방법 등)에 대한 몇 가지 지침을 만듭니다. Dev의 현실을 이해함으로써 (더 많은 기능, 더 빠른, gogogogo!) 우리는 ops가 개발자의 요구에 더 적합한 서버와 클러스터를 만들도록 할 수있었습니다.
• 전체 배포 품질도 크게 향상되었습니다. 팀에서 배포를 처리하여 운영팀과 개발자 모두를 완벽하게 파악했습니다. 이것은 개발자가 패키지와 한 페이지의 문서를 "Install this!"라고하는 운영진에게 넘겨주는 "코드 핸드 오프"와 관련된 많은 문제를 제거했습니다.

전반적으로, 하루에 한 번 또는 한 달에 한 번 생산 환경을 업데이트하거나 고객 수 또는 비즈니스 모델 수에 관계없이 모든 기업이 더 나은 커뮤니케이션, 더 나은 도구, 더 나은 가시성, 더 빠른 피드백, 기타

우리 팀과 저는 "일회성"을 개발할 책임이 있습니다. 한 번 완료된 제품은 유지 보수를 위해 고객에게 제공되거나 경우에 따라 유료로 관리됩니다.

신뢰할 수 있고 입증 된 제품을 배송하기 위해서는 고객의 지속적인 피드백을 처리 할 수있는 견고한 개발 파이프 라인을 유지해야합니다.

클라이언트는 DevOps에 관심이 없지만 (대부분의 경우) 여전히 도움이됩니다. DevOps를 사용하면 새로운 빌드를 신속하게 추진할 수 있으므로 클라이언트는 몇 시간이 아닌 몇 분 안에 피드백을 볼 수 있으며 Jenkins / Travis를 통한 테스트에서 오류 / 버그를 발견 할 수도 있습니다.

프로젝트 간 배포 전략이 동일하게 유지되도록 응용 프로그램 컨테이너화에 중점을 둡니다. Docker를 사용하면 응용 프로그램을 고객에게 쉽게 전달할 수 있습니다.

DevOps가 절약 한 비용은 결정하기 어렵습니다. 파이프 라인에 사용하기로 선택한 소프트웨어 (Travis, Jenkins, Puppet 등)의 추가 비용이 발생하지만 버그를 수정하고 고객에게 신속하게 피드백을 제공함으로써 시간과 비용을 절약 할 수 있습니다. 빠른 응답 시간으로 고객을 만족시키고 지갑을 행복하게 유지하십시오.

소프트웨어를 수축 포장 제품으로, 완전히 설치 및 지원되는 배포 및 장치의 내장 코드로 소프트웨어를 제작하는 회사에서 일했습니다. 이러한 모든 회사에서 DevOps는 개발을위한 필수 지원을 제공합니다.

• 알려진 제어 된 컴파일러, 라이브러리 및 기타 빌드 도구 구성을 사용하여 자동화되고 재현 가능한 소프트웨어 빌드.
• 회귀 테스트 및 새로운 기능 테스트를위한 자동화 된 반복 가능한 시스템 테스트
• 기타 자동적이고 정기적 인 조치 (예 : 번역가가 확인하고 기술 저자가 사용자 매뉴얼에 통합 할 수 있도록 지원되는 모든 언어로 지속적으로 업데이트되는 샘플 스크린 샷).

모든 경우에 개별 개발자 가 일회성으로 할 수 있지만 개발자 시간을 잘 활용하지 못하거나 자동화 된 빌드와 동일한 구성 제어를 보장 할 수 없습니다.

이전에 소프트웨어 개발 및 구현에 대한 활동은 부서 간 긴밀한 통합이 필요하지 않았습니다. 그러나 오늘날에는 모든 부서 (개발, IT 운영, 품질 보증 등)를 긴밀히 협력해야합니다.

개발자에게 변화는 그들이 지불하는 것입니다. 비즈니스는 항상 현대 세계에 맞게 변경해야합니다. 이러한 이해를 통해 개발자는 가능한 최대 변경 횟수를 생성 할 수 있습니다. IT 전문가는 변화에 해를 끼치는 이해가 다릅니다. 그들 각각은 그것이 올바르게 작동하여 비즈니스에 도움이된다고 생각합니다. 실제로, 우리가 그것들을 개별적으로 고려한다면, 그들은 둘 다 맞습니다.

모든 직원은 자신이 단일 프로세스의 일부라는 것을 이해해야합니다. DevOps는 사고를 육성하여 모든 사람의 개인적인 결정과 행동이 단일 목표의 실현을 향해야한다는 것을 깨달을 수 있습니다. 그리고 성공은 개별 역할의 성공이 아니라 전체 개발-배달주기를 기준으로 측정해야합니다. 개발자와 유지 보수 전문가 간의 긴밀한 협력의 결과로, 두 분야의 최고 성과를 달성하고 사용자의 이익을 위해 이들을 결합한 새로운 세대의 엔지니어가 구성됩니다. 이는 개발, 구성 관리, 데이터베이스 관리, 테스트 및 인프라 관리에 경험이있는 부서 간 팀의 모습에서 나타납니다.

따라서이 방법론은 SaaS뿐만 아니라 유용합니다.

전혀. 이 스레드에 대한 훌륭한 예가 이미 있지만 내 일화를 공유하고 싶습니다. 2001 년에 CD 제작과 관련된 릴리스로 소프트웨어 프로젝트를 물려 받았습니다. 릴리스 프로세스에 대한 문서에는 이전 엔지니어가 문서화 한 40 (!) 단계가 포함되어 있습니다. 여기에는 "이 구성 파일을 열고 41 행에서 .jar 파일의 이름을 변경하여 버전 번호를 포함하십시오. 새로운 릴리스 ".

우리는 빌드 프로세스의 모든 단계를 적극적으로 자동화하여 수작업으로 작성된 지침을 bash로 스크립트 된 'patch'와 같은 것으로 대체했습니다. 프로젝트 파일을 패치 가능하게 만들기 위해 타사 설치 도구 공급 업체와 티켓을 열어야했습니다.

프로세스가 자동화되면 'CD Jukebox'를 구입했습니다. 매일 밤 테스트가 끝나면 빌드 머신은 자동으로 새 설치 CD를 만듭니다. 우리 테스터는 다음날 아침에 와서 디스크를 잡고 모든 것이 설치 가능한지 확인할 수있었습니다.

소프트웨어를 서비스로 배포 할 수있을 때 피드백 루프가 더 엄격하지만 자동화, 피드백, 사이클 시간, 소규모 릴리스 등의 핵심 원칙이 모두 적용됩니다.