이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 핵심 오픈 소스 관행과 효과적인 오픈 소스 개발 및 커뮤니티 참여에서 수행하는 역할 설명
- 폐쇄 소스 소프트웨어 개발과 비교할 때 이러한 개념의 차이점(및 유사점)을 명확히 합니다.
요구 사항은 모든 형태의 소프트웨어 개발에 대한 핵심 고려 사항이며 오픈 소스도 다르지 않습니다. 그러나 요구 사항 수집의 형태와 기능은 많은 기존 소프트웨어 개발 환경에서 사용되는 '폭포' 요구 사항 프로세스와 크게 다릅니다.
일반적인 오픈 소스 개발 모델에 대한 다음과 같은 일반적인 개요를 고려하십시오.
이 그래픽에서 볼 수 있듯이 '요구 사항'은 일반적으로 사용자 또는 개발자의 '기능 요청'의 형태로 제공되며 개발의 더 반복적이고 민첩한 특성(자세한 내용은 곧)으로 인해 오래 걸리지 않습니다. , 오픈 소스 소프트웨어 개발을 위한 장기간의 요구 사항 단계.
이는 변화하는 요구 사항이나 프로젝트가 운영되는 기술 및 비즈니스 환경에 신속하게 대응할 수 있는 능력을 활용한다는 점에서 고유한 장점이 있습니다. 그러나 프로젝트의 장기 전략적 목표를 관리하는 데 도움이 되는 핵심 오픈 소스 유지 관리자뿐만 아니라 상당한 개발자 규율이 필요합니다.
이러한 원칙의 대부분은 Agile Software Development Methodology의 일부이며 실제로 많은 유사점이 있습니다. 이후 섹션에서 약간의 차이점에 대해 논의할 것입니다.
점점 더 많은 소프트웨어 개발이 소프트웨어 설계에 Agile 및/또는 DevOps 접근 방식을 채택했지만, 여전히 기존의 폐쇄형 소스 또는 독점 소프트웨어 개발 모델의 상당 부분이 있습니다. 여기에 설명된 것처럼 더 '폭포' 접근 방식을 취합니다.
이 접근 방식은 문서의 완전성 측면에서 몇 가지 장점이 있지만(예:) 일반적으로 오픈 소스 소프트웨어 프로젝트에서 사용하는 더 반복적이거나 민첩한 접근 방식보다 너무 무겁고 속도가 훨씬 느린 것으로 간주됩니다. 또한 대부분의 오픈 소스 소프트웨어 프로젝트에 존재하는 일반적인 지리적으로 분산된 개발 팀으로 구현하는 것이 일반적으로 더 어렵습니다.
향후 모듈에서 업스트림 오픈 소스 프로젝트 작업에 대해 더 자세히 다룰 것이지만 이러한 커뮤니티에 참여하기 위한 효과적인 개발 사례를 구축하기 전에 이해해야 하는 대부분의 오픈 소스 프로젝트의 몇 가지 공통된 특성이 있습니다.
이것이 완전한 목록은 아니지만 거의 모든 오픈 소스 프로젝트의 몇 가지 핵심 특성은 다음과 같습니다.
- 지리적으로 분산된 개발 팀
- 투명한 커뮤니케이션 및 개발 관행
- 분산되고 투명하고 열린 의사결정
- 능력주의 문화(일을 하는 사람들이 프로젝트 방향을 이끄는 데 도움이 됨)
- 조직 변화에 대한 회복력
- 자기조직화
- 확장 가능한 프로젝트 개발/관리 모델
- 모든 코드 기여에 대한 동료 검토
성공적인 오픈 소스 개발 노력의 특징은 사용 가능한 참여의 양에 따라 프로젝트를 효과적으로 확장할 수 있는 능력입니다. 다음은 이를 실현하는 구조의 예입니다.
소규모 프로젝트에는 일반적으로 단일 관리자와 작은 코드 본문이 있습니다. 릴리스는 일반적으로 엄격하게 예약되지 않으며 '준비가 되면' 발표됩니다.
프로젝트가 약간 커지기 시작하면 여전히 불규칙한 릴리스 주기가 있지만 코드베이스를 하위 시스템으로 나누기 시작할 수 있습니다. 이 단계에서 그들은 여전히 일반적으로 한 명의 유지 관리자만 가지고 있습니다.
프로젝트가 중간 규모로 이동함에 따라 일반적으로 단일 유지 관리자가 있지만 릴리스 기준은 정기적으로 예정된 릴리스와 함께 더 엄격해지기 시작할 것입니다.
프로젝트가 중간 규모의 표시를 통과하면 기본 유지 관리자가 더 이상 프로젝트의 모든 단일 하위 시스템을 돌볼 수 없는 위임된 유지 관리에 관심을 갖기 시작합니다. 특정 하위 시스템에 대한 전문성이나 열정을 갖고 있는 신뢰할 수 있는 개발자/기여자가 특정 코드 본문을 보살피도록 임명됩니다.
프로젝트가 '대형' 범주로 전환되면 몇 가지 변경 사항이 있습니다. 하위 시스템의 추가 분할(때로는 훨씬 더 개별적인 부분으로)과 더 자세한 수준의 위임된 유지 관리 및 릴리스가 정기적일 뿐만 아니라 관리자가 감독합니다. Linux 커널의 LTE(Long-term Evolution) 커널 분기와 같은 전용 유지 관리자 집합입니다.
이러한 구조 및 개발 모델의 핵심 요소는 서로 다른 프로젝트 하위 시스템에 대한 책임을 하위 시스템의 코드에 대한 최종 책임이 있는 '유지 관리자'에게 위임하여 작동한다는 것입니다. 이를 통해 전체 프로젝트 관리자가 프로젝트의 더 큰 전략 및 아키텍처 그림에 집중할 수 있는 수준의 전문화 및 감독이 가능합니다.
성공적인 프로젝트가 이 확장 가능한 개발 모델을 실제로 구현하는 방법의 예로 세계에서 가장 성공적인 오픈 소스 프로젝트 중 하나인 Linux 커널을 고려하십시오.
Linus Torvalds는 여전히 프로젝트에 대한 전반적인 영향력을 유지하고 있지만 커널의 일부인 여러 하위 시스템에 대해 분산된 유지 관리자 집합에 크게 의존합니다. 모든 오픈 소스 프로젝트가 이 크기로 성장하거나 이 수준의 제어가 필요한 것은 아니지만, 크고 다양한 기여자 기반에 대해 효과적인 제어를 구현할 수 있는 방법을 고려하는 것은 유익합니다.
이제 몇 가지 오픈 소스 프로젝트 특성과 조직 모델을 살펴보았으므로 오픈 소스 프로젝트 내에서 성공적인 디자인 관행의 몇 가지 핵심 교리를 고려해 보겠습니다.
디자인이 오픈 소스 프로젝트 내에서 어떻게 나타나는지, 그리고 그것이 보다 전통적인 소프트웨어 개발과 어떻게 다른지 고려하는 것이 중요합니다. 주요 고려 사항은 세 가지 주요 영역으로 나뉩니다.
- 공개된 디자인
- 기타 모집
- 승인을 위한 디자인
다음 페이지에서 이에 대해 좀 더 자세히 살펴보겠습니다.
개방성과 투명성은 오픈 소스 개발의 특징이며 디자인도 다르지 않습니다. 다음은 '공개 설계'에 대한 몇 가지 모범 사례입니다.
- 프로젝트가 선호하는 커뮤니케이션 플랫폼에서 조기에 자주 커뮤니케이션
- 코드 예제 및 가능한 참조 구현 제공
- 피드백 예상
- 좋은 피드백을 인정하고 기여를 다시 작업하십시오.
- 특히 잠재적 기여자의 질문에 신속하게 응답
- 다른 사람이 작업을 수행할 경우 디자인을 적용할 의사가 있음을 나타냅니다.
- 첫 번째 설계가 모듈화되지 않은 경우에도 모듈화 계획
유연성도 여기에서 핵심 요소입니다. 기존의 비공개 소스 프로젝트보다 더 많은 사람이 코드를 평가하고 보고 있다는 사실을 이해하는 것은 최상의 디자인 결정을 내리고 프로젝트에 코드 기여를 승인하는 데 중요합니다.
모듈식 접근 방식을 취하는 것(또는 최소한 코드를 모듈식으로 만들 수 있는 방법을 계획하는 것)은 모놀리식 디자인이 더 널리 퍼져 있는 기존 개발 모델과 다를 수 있습니다. 처음부터 모듈화에 대해 생각하는 것은 전체 오픈 소스 프로젝트에 도움이 될 뿐만 아니라 그 자체로 좋은 엔지니어링 관행입니다.
협업은 오픈 소스 프로젝트에서 게임의 이름이며 일반적인 기업 또는 폐쇄 소스 개발 노력에서 일반적으로 사용되는 것보다 훨씬 더 깊은 방식입니다.
오픈 소스에서 도움을 줄 다른 사람을 모집할 때 고려해야 할 몇 가지 사항은 다음과 같습니다.
- 자신의 가려움을 긁으세요. 다른 사람이 당신을 대신해 긁지 않을 것입니다... 같은 가려움이 없다면
- 개발 부담을 줄이려면 다른 사람을 끌어들이는 코드를 작성하십시오.
- 귀하의 기여 범위가 다른 개발자를 끌어들일 수 있을 만큼 광범위해야 합니다.
- 누군가가 당신의 코드에 관심을 보인다면 반응하고 능동적으로 행동하십시오.
- 경쟁자라고 놀라지 마세요
- 종종 오픈 소스 프로젝트의 기능에서 가장 많은 것을 얻을 수 있는 회사가 동일한 비즈니스 라인에 있습니다.
- 경쟁사 간의 오픈 소스 협업의 풍부한 역사가 있습니다.
다른 사람들을 염두에 두고 코드를 디자인하는 것은 보다 좁은 범위의 개발 관행보다 더 많은 시간과 노력이 필요하지만 효과적인 오픈 소스 프로젝트의 기여자 기반의 승수 효과를 목격할 때 결국 가치가 있습니다.
지금까지 말한 모든 것을 바탕으로 이 시점에서 오픈 소스 참여의 목표는 디자인과 아이디어를 효과적으로 수용하는 방법을 생각하는 것이어야 합니다.
이를 돕기 위해 고려해야 할 사항은 다음과 같습니다.
- 가능한 가장 작은 부분으로 작성되고 통합되도록 기여를 설계하십시오.
- 패치가 작을수록 유지 관리자가 더 쉽게 통합할 수 있습니다.
- 오픈 소스 프로젝트는 확장성을 촉진하기 때문에 모듈식 접근 방식을 선호합니다.
- 설계 범위를 적절하게 지정하고 필요한 경우 계획을 세분화합니다.
- 더 큰 변경 사항은 구체적인 이정표가 있는 일련의 작은 변경 사항으로 채택될 가능성이 높습니다.
- 컨텍스트를 제공하기 위해 전체 계획을 전달하되, 즉시 보편적인 동의를 기대하지 마십시오.
- 가능한 한 다른 프로젝트 하위 시스템에 방해가 되지 않도록 합니다.
- 핵심 시스템 구성 요소를 변경할 필요가 있다고 생각되면 시작하기 전에 훨씬 더 사전에 의사 소통하고 유지 관리자에게 의견을 요청하십시오.
코드를 통합하거나 나중에 유지 관리해야 하는 다른 개발자 또는 유지 관리자의 입장이 된다면 승인을 위한 디자인에 대한 적절한 관점을 제공하는 데 도움이 될 것입니다.
새로운 방식으로 디자인하는 것에 대해 생각하는 것 외에도 오픈 소스 프로젝트에서 의사 결정이 내려지고 전달되는 방식을 이해하는 것이 중요합니다. 종종 아래 나열된 원칙은 기존 소프트웨어 개발 방법론에서 약간 벗어난 것입니다.
- 일반적으로 "하위 시스템 유지 관리자"라고 하는 신뢰할 수 있는 대리인을 지정하여 결정을 분산합니다.
- 신뢰는 과거의 좋은 참여 기록과 작은 문제에 대한 현명한 결정으로 구축됩니다.
- 분산된 특성은 투명성에 대한 추가 초점이 필요합니다.
- 토론은 항상 열린 상태에서 이루어집니다.
- 예: 메일링 리스트, IRC, Slack 등
- 종종 토론 자체가 결과에 대한 문서화된 기록입니다(따라서 아카이브가 중요함).
간단히 말해서, 전자 형식의 커뮤니케이션은 오픈 소스 프로젝트에 중요할 뿐만 아니라 일반적으로 직접적인 개발 동료와만 커뮤니케이션할 수 있는 기존 소프트웨어 프로젝트보다 더 많은 토론 빈도와 깊이가 있습니다.
이와 다소 다른 방식으로 의사소통하기 위해 자신을 이해하고 준비하는 것이 중요하며 이 교육의 뒷부분에서 이에 접근하는 방법에 대해 더 자세히 다룰 것입니다.
케이던스와 관련하여 오픈 소스 개발 프로세스가 어떻게 작동하는지 더 잘 이해하기 위해 이 교육의 앞부분에 제공된 그래픽을 다시 가져와 보겠습니다.
오픈 소스 프로젝트는 '일찍 릴리스, 자주 릴리스'라는 만트라에 따라 실행됩니다. 위의 그래픽을 기반으로 하면 이것이 분명해 보일 수 있지만 개발 프로세스와 케이던스, 특히 다음과 같은 요소에 영향을 줍니다.
- 처음부터 코드의 완성도를 기대하지 마십시오
- 목표를 달성하기에 충분할 때 코드를 제출하십시오.
- 코드 안정화는 커뮤니티 프로세스의 일부입니다.
- 개발자 커뮤니티가 코드를 안내하고 구성하는 데 도움을 줄 수 있습니다.
- 가능한 가장 작은 합리적인 청크로 기능 구현
- 작은 변경은 테스트 및 통합이 더 쉽습니다.
- 코드를 재작업(여러 번 가능)할 수 있도록 준비하십시오.
오픈 소스 프로젝트에서 코드 제출/재작업의 주기는 일반적으로 보다 전통적인 소프트웨어 개발 환경에 익숙한 개발자에게 가장 큰 차이점이며 오픈 소스 프로젝트에서 사용되는 더 빠른 속도는 익숙해지는 데 약간의 시간이 걸릴 것입니다. 그러나 이러한 작업 방식에 익숙해지면 이러한 방식으로 작업하는 것이 더 자연스럽고 거의 제2의 천성이 된다는 것을 알게 될 것입니다.
이 교육의 이전 섹션에서 오픈 소스 프로젝트 및 해당 커뮤니티와 함께 작업하는 역학이 엄격하게 기업 또는 내부 개발 노력에 익숙할 수 있는 것과 약간 다르다는 것이 분명하기를 바랍니다.
커뮤니티의 개념은 이해하기 어렵지 않습니다. 우리 대부분은 커뮤니티에 살고 있으며 일상 생활에서 다양한 수준의 커뮤니티를 경험합니다. 그러나 오픈 소스 프로젝트에 적용할 때 고려해야 할 몇 가지 사항이 있습니다.
- 두 커뮤니티가 완전히 똑같지는 않습니다
- 커뮤니티는 개별 회사에서 작동하지 않습니다
Linux 커널 또는 Kubernetes와 같은 잘 알려진 오픈 소스 프로젝트 커뮤니티가 있습니다. 이 커뮤니티에는 몇 가지 유사점은 있지만 일반적으로 시작 방법, 적용되는 거버넌스 모델 및 경험의 결과인 다른 '성격'이 있습니다. 그들의 창립 멤버 중.
많은 조직이 현재 오픈 소스에 투자하고 있는 것이 사실이지만(예: Kubernetes는 Google에서 시작함) 오픈 소스 프로젝트 커뮤니티는 개별 회사에서 작동하지 않으므로 조직을 위해 작업을 수행하는 것은 지속적인 기여와 좋은 일을 하고 있습니다(좀 더 자세히 설명하겠습니다).
오픈 소스 프로젝트가 조직의 '무료 개발자'가 아니라는 점을 이해하는 것은 매우 중요합니다. 그렇게 가정하면 나중에 문제가 될 수 있습니다. 다음 몇 페이지에서 우리는 오픈 소스 커뮤니티에 참여하기 위한 몇 가지 모범 사례를 제공하고 일부 기본 커뮤니케이션 도구 에티켓이 이러한 대규모 분산 개발 팀과 효과적으로 작업하는 데 도움이 되는 방법을 보여줍니다.
커뮤니티와 직접 작업을 시작하기 전에 올바른 발판을 마련할 수 있는 최상의 접근 방식을 조사하고 준비하는 데 약간의 시간을 들이는 것이 종종 도움이 됩니다. 이 연구의 일부는 귀하(또는 귀하의 조직)가 커뮤니티를 지원하기 위해 무엇을 준비하고 있는지 살펴보는 것입니다.
무엇을 제공할지 결정
오픈 소스 프로젝트는 단순한 코드 그 이상입니다. 다음과 같은 분야에 기여할 수 있습니다.
- 소프트웨어 개발
- 테스트/품질 보증
- 문서
- 사용자 경험/GUI 디자인
- 전도/커뮤니케이션
이러한 여러 영역에 대한 전문 지식이 있는 경우 여러 역할에 확실히 기여할 수 있습니다.
시간 약속 결정
귀하 및/또는 귀하의 조직이 테이블에 가져올 수 있는 시간 약속의 종류에 대해 현실적이라면 도움이 됩니다. 대부분의 커뮤니티는 공허한 도움 제안보다 완성된 작업을 더 존중하므로 현실적으로 전달할 수 있는 것에 전념하십시오.
또한 당신의 헌신은 당신뿐만 아니라 당신이 대표하는 조직에도 반영된다는 것을 기억하십시오.
커뮤니티에 참여하기 위한 계획을 세울 때 그들이 누구이며 어떻게 작동하는지에 대한 몇 가지 중요한 사항을 아는 것이 중요합니다.
분명히 커뮤니티의 역학을 이해하는 데 있어 가장 중요한 부분은 커뮤니티가 어디에서 어떻게 의사 소통하는지 이해하는 것입니다. 일부 커뮤니티는 여전히 이메일을 선호합니다. 다른 커뮤니티는 IRC(Internet Relay Chat), Slack, Github 문제, Discord 또는 기타 포럼 도구와 같은 비동기 포럼으로 마이그레이션했습니다.
어떤 플랫폼이 사용되고 있는지 파악하는 데 시간을 할애할 뿐만 아니라 어떤 종류의 질문을 받았는지, 어떻게 답변을 받았는지, 어떤 다른 정보 소스(버그 추적기, Wiki 등)가 참조되는지 알아보기 위해 잠시 숨어 있습니다. 커뮤니티의 답변에서.
이 조사를 수행하고 커뮤니티에서 질문하기 전에 답변을 찾으려고 노력함으로써 기존 커뮤니티 회원에게 귀하가 훌륭한 커뮤니티 회원이 되는 것에 대해 진지하다는 것을 보여주고 있으며 이는 큰 효과가 있습니다.
커뮤니케이션 포럼에 숨어서 숙제를 하는 것도 프로젝트를 위한 거버넌스 모델을 이해하는 데 도움이 됩니다. 일부 프로젝트는 명확한 명령/보고서 체인이 있는 계층 구조입니다. 일부 프로젝트에는 더 평평한 조직 모델이 있습니다.
거버넌스의 역학을 이해하면 기여 준비를 더 잘할 수 있을 뿐만 아니라 커뮤니티에서 어떤 질문에 대답하는 데 가장 적합한지 알 수 있습니다.
오픈 소스 프로젝트는 기본적으로 지리적으로 분산된 팀을 활용하지만 기여나 아이디어를 얻는 데 도움이 필요하거나 다른 사람에게 도움을 줄 수 있는 위치에 있는 경우가 많기 때문에 커뮤니티 구성원을 개인적으로 알아가는 것이 중요합니다. 받아들였다. 가능하면 새로운 프로젝트 구성원이 기존 프로젝트 베테랑을 알 수 있도록 많은 프로젝트에서 조직하는 대면 또는 가상 모임에 참여하십시오.
자, 조사를 마쳤으며 이제 오픈 소스 커뮤니티에 참여할 준비가 되었습니다! 약혼에서 생각해야 하는 네 가지 주요 영역이 있습니다.
커뮤니티를 위해 작업 중인 내용을 '비공개로' 작업하지 마십시오. '일찍 릴리스, 자주 릴리스'의 조언을 기억하십시오. 일반적으로 커뮤니케이션 채널을 확인하여 계획한 일이 이미 완료되었는지 확인하는 것뿐만 아니라 새로운 기능을 구축하거나 버그를 수정하려는 의도를 표시하여 커뮤니티(및 유지 관리자)가 기여를 수락하는 가장 좋은 방법을 계획하는 데 도움이 될 수 있습니다. 커뮤니티는 귀하가 성공하기를 원하므로 귀하가 기여를 준비할 때 도움을 받는 것이 좋습니다.
오픈 소스 프로젝트에 대한 기여는 대부분 다른 프로젝트의 코드를 포함하고 있습니다. 기여에 사용한 다른 작업/라이브러리/개발을 인정하고 커뮤니티가 전체 프로젝트에 도움이 될 수 있는 이러한 외부 자원도 찾도록 도와주세요.
소스 코드의 명백한 기여 외에도 조직에서 하드웨어 선물을 주선하거나(가능한 경우) 팀을 위한 모임을 주선하거나 단순히 새 구성원을 위한 질문에 답하는 데 시간을 보내는 것과 같이 커뮤니티에 되돌릴 수 있는 다른 방법을 고려하십시오.
소스 코드는 확실히 중요하지만, 진정으로 성공적인 공개SW 프로젝트는 '코드가 아닌' 기여에서도 번창합니다.
언젠가는 귀하의 조직이 커뮤니티를 종료해야 할 수 있습니다. 커뮤니티에 들어온 것보다 더 나은 상태로 커뮤니티를 떠나도록 노력하십시오. 이를 위해 할 수 있는 몇 가지 간단한 작업은 다음과 같습니다.
- 후임자 또는 코드를 인수할 사람 식별
- 그 후계자를 나머지 커뮤니티에 소개
- 귀하의 퇴장으로 인해 변경해야 할 사항에 대해 계획할 시간을 가질 수 있도록 가능한 한 빨리 커뮤니티에 알리십시오.
커뮤니티를 탈퇴하는 경우에도 귀하의 행동은 귀하 및/또는 귀하의 조직에 반영된다는 점을 기억하십시오.
대부분의 프로젝트에서 사용되는 두 가지 주요 커뮤니케이션 도구 유형은 일종의 메시징 시스템(이메일, Slack, IRC 등)과 일종의 문제 또는 버그 추적 소프트웨어(JIRA, Github Issues 등)입니다. 다음은 각 유형의 플랫폼을 효과적으로 사용하기 위한 몇 가지 일반적인 팁입니다.
- 대부분의 메시지/통신은 영어로 되어 있습니다.
- 피드백은 단기/집중 버스트로 올 가능성이 높습니다.
- 개인적으로 코드에 대한 비판을 받아들이지 말고 좋은 제안을 받아들이고 코드를 재작업하십시오.
- 코드를 리뷰하는 경우 코드/아이디어를 비판하되 사람을 비판하지 마십시오.
- 시간대를 알고 즉각적인 응답을 기대하지 마십시오.
- 커뮤니티에서 올바른 방향으로 안내할 수 있도록 질문하는 경우 '작업을 보여주세요'
- 버그 보고서를 간결하지만 철저하게 유지
- 보고하려는 내용이 이미 있는지 확인하려면 버그/문제 시스템을 확인하세요.
- 버그를 유발하는 테스트 코드를 포함하여 관련 정보를 충분히 제공합니다.
- 버그를 수정해야 하는 커뮤니티의 의무는 없음을 이해합니다. 직접 수정해야 할 수도 있다는 사실에 대비하세요.
- 버그를 수정하거나 해결 방법을 찾으면 정보에 대한 관련 업데이트를 제공하십시오.
오픈 소스 커뮤니티와 처음 작업을 시작할 때 고려해야 할 사항이 많이 있습니다. 그러나 다음 네 가지 사항을 염두에 둔다면 대부분의 상황을 다룰 수 있을 것입니다.
각 커뮤니티는 다르지만 모든 '패치'는 전체 전체에 맞아야 합니다.
성공적인 커뮤니티는 동기 부여된 사람들에 의해 운영되며 항상 돈에 의해 동기 부여되는 것은 아닙니다. 동료 인식과 지위는 종종 오픈 소스에서 강력한 힘입니다.
커뮤니티 참여는 주기입니다. 변화를 예상하고 정기적으로 새 회원을 영입할 수 있도록 준비하십시오.
오픈 소스의 리더십은 부여되는 것이 아니라 얻는 것이며, 당신이 일하는 조직과 그들의 평판이 반드시 특정 프로젝트에서 당신에게 영향력을 부여하는 것은 아닙니다.
리더십과 통제 사이에는 큰 차이가 있음을 기억하는 것이 중요합니다. 대부분의 오픈 소스 커뮤니티는 프로젝트 방향을 과도하게 제어하려는 시도를 주저하지만 참여자가 주도권을 얻기 전에 가치 있는 기여를 할 것으로 기대합니다.
대담함과 적극적 참여 사이에서 적절한 균형을 유지하면서 피드백을 받고 코드 기여를 재작업할 만큼 겸손해지면 시간과 연습이 필요하지만 이 균형을 염두에 두는 것은 올바른 방향으로 안내하는 데 도움이 됩니다.
이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 지속적인 통합, 테스트 및 배포 설명
- 이러한 관행을 구현하는 데 사용되는 다양한 도구를 설명합니다.
- 이러한 개념을 구현하는 데 드는 비용과 이점을 명확히 합니다.
옛날 옛적에 대부분의 소프트웨어는 종종 같은 위치에서 자주 연락하는 비교적 작은 개발자 그룹에 의해 작성되었습니다. 책임의 조정 및 분할은 간단한 방식으로 수행될 수 있습니다.
개정 관리 시스템 은 프로젝트에서 작업하는 한 명 이상의 기여자를 수용하기 위해 오래 전에 개발되었습니다. 일반적으로 프로젝트의 마스터 사본을 저장하는 저장소가 있으며, 한 명 이상의 개발자가 변경한 다음 체크인할 수 있습니다.
많은 하위 시스템이 있는 프로젝트의 여러 위치에서 작업하는 개발자가 많으면 상황이 더 복잡해집니다. Linux 커널은 최초의 대규모 분산 개발 프로젝트였으며, 그 창시자인 Linus Torvalds는 분산 개발을 합리화하기 위한 git** **시스템을 발명했습니다.
그러나 개정 관리 시스템은 다양한 기여자 그룹이 실제로 함께 작동하는지 확인하는 문제를 해결하지 못합니다. 한 세트의 새로운 코드 또는 버그 수정이 다른 세트와 충돌하지 않습니다. 그것은 테스트를 통해서만 가능합니다.
테스트에도 다음과 같은 여러 단계가 필요합니다.
- 중복되는 변경 세트를 동시에 적용할 수 있거나 충돌을 일으킬 수 있습니다(git과 같은 우수한 개정 제어 시스템은 이 작업의 대부분을 처리할 수 있지만 여전히 사람의 개입이 필요한 경우가 많습니다).
- 모든 변경 사항이 적용되면 프로젝트도 컴파일됩니까? 예를 들어, 한 패치 세트가 다른 패치 세트에 필요한 헤더 파일을 제거할 수 있습니다. 이것은 개정 관리 시스템에 의해 선택되지 않습니다.
- 가능한 모든 대상에서 작동합니까? 이는 다른 하드웨어(예: x86 대 ARM) 또는 다른 운영 체제(예: Linux 대 MacOS 또는 Windows) 또는 다른 라이브러리, 언어 또는 유틸리티 버전을 의미할 수 있습니다.
- working은 무슨 뜻인가요? 자신감을 주기에 충분한 대표적인 워크로드를 실행할 수 있는 중요하지 않은 테스트 제품군이 있습니까?
지속적 통합 기술은 테스트가 너무 자주 수행되어 문제가 오래 지속되지 않도록 하여 분산된 개발자가 같은 페이지를 유지하는 데 도움이 됩니다.
프로젝트는 변경 사항을 빠르게 흡수하고 실시간으로(보통 하루에 여러 번) 자동화된 테스트를 실행하여 조화로운지 확인합니다. 일반적으로 프로세스는 다음과 같습니다.
지속적 전달 및 지속적 배포의 전체 프로세스는 세 가지 개별 단계 또는 단계로 설명할 수 있습니다.
- 지속적인 통합
변경 사항은 가능한 한 자주 메인 브랜치("마스터")에 병합되어야 합니다. 자동화된 빌드** **는 가능한 많은 소프트웨어 및 하드웨어 변형에서 실행됩니다. 갈등은 발생하는 즉시 해결됩니다.
- 지속적인 테스트/배송
릴리스 프로세스가 자동화되고 프로젝트가 빌드 소비자에게 제공될 준비가 되었습니다. 모든 관련 플랫폼에서 철저한 테스트가 수행됩니다.
- 지속적인 배포
제품은 다시 한 번 자동화된 방식으로 고객에게 출시됩니다.
이러한 단계 사이의 시간 간격은 가능한 한 0에 가깝습니다. 완벽한 세상에서 개발자 변경 사항은 당일 또는 몇 분 안에 최종 사용자 고객에게 도달할 수 있습니다. 이러한 용어는 다소 다르게 정의될 수 있습니다. 예를 들어 지속적 통합은 전달과 배포를 모두 포함하는 것으로 간주할 수 있습니다.
지속적인 배포 및 배포 주기의 핵심 구성 요소는 오픈 소스 코드 기반에서 자주 실행되는 자동화된 지속적인 테스트입니다. 중첩 테스트 주기의 개념은 지속적인 통합(작은 변경 세트에서 기억)을 통해 통합되는 코드가 철저하게 테스트되고 잠재적인 문제를 쉽게 찾아낼 수 있도록 하는 데 사용됩니다. 예는 다음과 같습니다.
오픈 소스 프로젝트의 겹치는 릴리스 주기는 전체 소프트웨어 품질을 더 엄격하게 제어하면서 자주 릴리스할 수 있는 기능을 제공합니다.
분명히 소프트웨어 개발에서 공짜는 없기 때문에 지속적인 배포 및 배포와 관련된 비용과 이점을 고려하는 것이 중요합니다. 다음은 비용 및 이점의 몇 가지 예입니다.
- 변경 사항은 최소한 하루에 한 번, 매우 자주 병합되어야 하므로 개발자에게 부담이 될 수 있습니다.
- 저장소는 기여할 때마다 스크립트 자동화 테스트를 실행하는 지속적 통합 서버**에서 모니터링해야 합니다. 이를 수행하려면 직원을 할당해야 합니다.
- 자동화된 테스트를 수행하고 결과를 보고하고 적절한 조치를 취하려면 스크립트 및 기타 도구를 실행해야 합니다. 이 인프라를 준비하는 데 많은 작업이 필요할 수 있습니다.
- 개발자는 잘못된 경로로 이동하여 수정 가능한 실수를 합성하거나 서로 방해하지 않으며 결국 귀중한 시간을 절약할 수 있습니다.
- 빌드 단계는 완전히 자동화되어 있으며 빌드 테스트가 필요할 때마다 모든 작업이 사전에 완료되었습니다.
- 회귀(작동 중인 제품을 중단시키는 버그)를 최소화할 수 있습니다. 즉, 릴리스된 소프트웨어에는 버그가 더 적어야 합니다.
지속적인 통합 파이프라인을 설정하는 것은 쉬운 일이 아니며 제대로 하려면 상당한 경험과 노력이 필요할 수 있습니다. 그러나 “1온스의 예방은 1파운드의 치료 가치가 있습니다.” 작업을 덜 힘들게 만드는 데 도움이 될 수 있는 많은 기존 도구와 서비스가 있습니다.
잘 개발된 지속적 통합 소프트웨어 도구가 많이 있습니다. 이러한 제품에 대한 요약은 https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/을 참조하십시오. 이들 중 일부는 무료 도구이고 일부는 그렇지 않습니다.
다음은 가장 자주 사용되는 도구입니다.
- 젠킨스 - https://jenkins-ci.org
- 서클CI - https://circleci.com/
- 트래비스 - https://travis-ci.org/
- Github 무결성 - http://integrity.github.io/
한 가지 명심해야 할 점은 항상 새로운 도구가 개발되고 있으므로
Google 및/또는 다른 개발자와 지속적 통합을 위해 사용 중인 도구에 대해 논의합니다.
지속적 배포의 최신 소식을 확인하는 또 다른 방법은 Linux Foundation이 2019년 3월에 발표한 프로젝트인 **Continuous Delivery Foundation(CDF)**을 살펴보는 것입니다. CI/CD(지속적 제공 및 통합) 영역에서 중요한 프로젝트의 통합을 위한 벤더 중립적 홈입니다.
모범 사례를 수립 및 문서화하고, 지침을 마련하고, 교육을 제공함으로써 목표는 CI/CD 및 DevOps 사례를 전파 및 확산하고 제품 릴리스 프로세스를 개선하는 것입니다.
창립 프로젝트는 다음과 같습니다.
- Jenkins: OSS CI/CD 시스템
- Jenkins X: Kubernetes용 Jenkins
- Spinnaker: OSS 멀티클라우드 CD 플랫폼
- Tekton: CI/CD 구성 요소에 대한 OSS 사양
이 재단의 **기술 감독 위원회(TOC; Technical Oversight Committee)**는 기여를 환영하는 개방형 거버넌스 모델을 가지고 있습니다.
이 이니셔티브의 창립 멤버는 다음과 같습니다.
Alauda, Alibaba, Anchore, Armory.io, Atos, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, HSBC, Huawei, IBM, JFrog, Netflix, Puppet, Rancher, Red Hat, SAP, Snyk, 및 SumoLogic.
참여 방법을 확인하거나 https://cd.foundation 에서 재단의 진행 상황을 확인하십시오.
이 섹션에서는 '내부 소스'라고 하는 프로세스인 내부 또는 일반적으로 '닫힌' 개발 노력에 오픈 소스 원칙을 적용하는 방법에 대한 정보를 제공합니다. 우리는 이 관행을 구현하는 실질적인 이유와 외부 청중과의 더 나은 오픈 소스 참여를 지원함으로써 조직에 어떻게 도움이 될 수 있는지 다룰 것입니다.
이 섹션이 끝나면 다음을 수행할 수 있습니다:
- 내부 소스가 무엇이며 내부 프로젝트 및 외부 오픈 소스 참여를 개선하는 데 어떻게 유용한지 설명하십시오.
- 조직에서 내부 소스 관행을 구현하기 위해 취할 수 있는 몇 가지 실용적인 단계를 설명하십시오.
Wikipedia에 따르면 내부 소스는 다음과 같이 정의됩니다. “ 조직 내에서 오픈 소스 소프트웨어 개발 모범 사례 및 오픈 소스와 같은 문화. 조직은 여전히 폐쇄 소스소프트웨어를 개발할 수 있지만 내부적으로 개발을 개방합니다. 이 용어는 2000년 Tim O'Reilly에 의해 만들어졌습니다.”
이 정의의 오픈 소스와 같은 문화 부분을 주목하는 것이 중요합니다. (이 교육에서 설명한 대로) 단순히 오픈 소스 개발 관행을 채택하면 내부적으로 개발 프로세스에 이점을 얻을 수 있지만 Inner Source를 최대한 활용하려면 개발 조직 내에서 보다 개방적이고 투명한 문화를 내부적으로 구축하는 것이 중요합니다(법률, 재무, HR 및 관리와 같은 지원 조직).
내부 소스 원칙이 내부 개발에 적합한 이유는 여러 가지가 있으며 가장 중요한 몇 가지를 아래에 나열하겠습니다:
보다 효율적이고 효과적인 개발
- 시장 출시 시간 단축
- 소프트웨어 재사용을 통한 개발 비용 절감
더 나은 조직 간 협업
- 조직 단위 간의 비용 및 위험 공유
- 프로그램 전반에 걸친 정보 교환
더 성공적인 소프트웨어 재사용
- 컴포넌트 제공자에서 누락된 역량 사용
- 구성 요소 공급자의 구제
향상된 지식 공유
- 커뮤니티 기반 학습
- 지식의 개방성과 가용성
외부 오픈 소스와의 더 나은 참여
- 개발자는 내부 개발 방식과 오픈 소스 개발 방식 간에 컨텍스트를 전환할 필요가 없습니다.
- 오픈 소스 개발자 모집/온보딩이 쉬워졌습니다.
다음으로 기존 소스 개발 방식과 내부 소스 개발 방식 간의 주요 차이점 중 일부를 다룰 것이며, 이 중 일부는 이 모듈에서 지금까지 다룬 내용을 기반으로 이미 친숙해 보일 것입니다. 또한 조직에서 이러한 관행을 구현하는 방법에 대한 실용적인 팁을 제공하려고 합니다.
이 모듈의 앞부분에서 다루었듯이 투명한 커뮤니케이션은 오픈 소스 프로젝트의 성공에 매우 중요하며 내부 소스에서도 똑같이 중요합니다.
또한 개인 이메일, 대면 회의 및 개인 전화 회의가 대부분의 내부 개발 프로젝트에서 일반적으로 사용되기 때문에 문화적 도전이 가장 큰 영역이기도 합니다. IRC, Slack 및 투명한 포럼과 같은 비동기식 도구를 사용하여 내부 커뮤니케이션 관행을 열면 프로젝트 간 협업을 촉진할 수 있을 뿐만 아니라 조직이 외부 오픈 소스 프로젝트에서 보다 효과적으로 작업할 수 있도록 준비할 수 있습니다.
어떤 도구를 선택하든(이메일 별칭이더라도) 사용 가능한 아카이브가 있는지 확인하고 프로젝트 방향에 대한 결정이 공개적으로 논의되어 모든 사람이 액세스할 수 있는 장소에 프로젝트 결정이 기록되도록 하십시오.
일반적으로 닫힌 저장소의 핵심 팀에서 수행하는 기존의 내부 개발과 달리 내부 소스 프로젝트는 정의에 따라 공개적으로 빌드해야 합니다. 이는 위에서 언급한 바와 같이 개방형 커뮤니케이션뿐만 아니라 개방형 소프트웨어 리포지토리, 게시된 로드맵 및 문서, 쉬운 '진입로' 및 기여를 위한 명확한 거버넌스 모델을 의미합니다.
또한 명확하고 투명한 버그 및 문제 추적이 필수입니다. 많은 팀은 핵심 팀에 속하지 않은 개발자와 사용자의 이러한 공개적인 참여를 내부 소스에 대한 가장 어려운 측면이라고 생각합니다. 프로젝트와 코드가 외부 조사에 노출되기 때문입니다. 그러나 이것의 긍정적인 측면은 더 나은 코드, 더 명확한 문서를 작성하고 외부 관점에서 아키텍처를 생각하도록 강요한다는 것입니다.
내부 소스 관행은 핵심 프로젝트 팀의 일부가 아닌 사용자를 참여시키는 것을 의미하므로 동료 검토의 개념이 매우 중요해집니다. 코드 검토 또는 짝 프로그래밍을 설정했을 수도 있지만 '외부' 개발자가 코드를 살펴보는 것은 완전히 다릅니다.
그들은 프로젝트의 코드 리뷰에 새로운 관점(그리고 처음에는 많은 질문)을 가져올 것입니다. 그러나 코드를 커밋하기 전에 팀에서 엄격한 검토를 수행할 필요가 없는 새로운 리소스도 제공합니다. 또한 이전에 외부 기여자가 코드 기반에 더 익숙해지고 팀이 코드 기반에 더 익숙해짐에 따라 신뢰의 웹과 아이디어의 교차 수정을 구축하는 데 도움이 됩니다.
우리는 이 모듈에서 오픈 소스의 반복적인 특성과 '일찍 릴리스, 자주 릴리스'라는 만트라를 모두 다루었습니다. 이는 일반적으로 정의된 로드맵과 함께 고정 릴리스 주기를 사용하는 대부분의 내부 개발 노력과 직접적인 대조를 이룹니다. 매우 빠르게 변경합니다.
개발에 대한 보다 반복적이거나 민첩한 접근 방식을 활용하고 코드 기반에 대한 작은 변경 사항을 통합함으로써 변화하는 요구 사항에 더 쉽게 적응할 수 있을 뿐만 아니라 프로젝트 아키텍처에서 한 번 성문화된 많은 회귀 또는 값비싼 버그를 방지할 수 있습니다. 수정하기 어렵습니다.
지속적인 통합/테스트/배포를 위해 이 교육의 앞부분에서 언급한 사례를 활용하면 내부 소스 프로젝트가 더 효과적으로 작동할 수 있을 뿐만 아니라 개발 팀이 이러한 스타일의 개발을 활용하는 외부 오픈 소스 프로젝트와 함께 작업할 수 있도록 교육할 것입니다.
내부 소스의 인적 자원 측면은 전통적인 계층 구조나 문화가 개발자를 특정 프로젝트에 할당하고 회사 내부의 다른 작업에 기여하는 것을 허용하지 않는 조직에서 때때로 매우 도전적입니다.
개발자가 코드베이스의 일부로 사용할 수 있는 조직 내부의 프로젝트에 참여하고 기여하도록 장려하는 방법을 고려하는 것이 중요합니다. 관리 팀이 이러한 종류의 팀 간 협업을 허용하도록 완전히 지원하고 스스로에게 인센티브를 제공하는지 확인하는 것도 중요합니다.
물론 여기에는 균형 잡힌 작업이 진행 중입니다. 여기서 개발자는 핵심 프로젝트에 효과적으로 기여해야 하는 동시에 가치 있는 기여를 할 수 있는 관련 프로젝트를 찾아야 합니다. 이러한 이유로 일반적으로 프로젝트 개발자가 공통 인프라 또는 플랫폼 코딩에 기여하도록 하는 것이 가장 좋습니다. 이에 대해서는 조금 더 자세히 설명하겠습니다.
이러한 종류의 팀 간 협업을 허용함으로써 얻을 수 있는 한 가지 주요 이점은 엔지니어가 자신의 팀을 넘어 조직에 가치 있는 공헌을 할 수 있다고 느끼는 경우 개발자 지식, 사기 및 유지율이 향상될 수 있다는 것입니다.
내부 소스를 구현하기 위한 모든 제안이 가능하지만 때로는 전통적인 명령 및 통제 계층이 존재하는 조직에서 매우 도전적입니다. 따라서 이미 상당한 상호 의존성이 있을 수 있는 소규모 프로젝트에서 내부 소스 '가장자리' 구현을 시작하는 것이 좋습니다.
예를 들어, 기본 라이브러리, 플랫폼 또는 공통 사용자 인터페이스 구성 요소는 일반적으로 이러한 종류의 노력에 적합한 후보이지만 여전히 문화적 변화(구성 요소 팀과 해당 구성 요소를 사용하는 팀 모두에서)와 잠재적인 코드 수정이 모두 필요합니다. - 성공적인 내부 소스를 허용하기 위한 아키텍처/문서화, 정리 등.
소규모 프로젝트로 초기 성공을 확보하고 내부 소스 프로그램을 평가하는 '일찍 릴리스, 자주 릴리스'라는 만트라를 따라 진행하면서 변경해야 할 사항을 확인하십시오. 가장 중요한 것은 이 과정이 매우 도움이 되지만 성공적인 열매를 맺는 데 몇 달(몇 년은 아니더라도)이 걸릴 수 있다는 점을 이해하십시오. 계속하십시오!