빌드 자동화 vs 배포 자동화 vs 지속적인 통합

보다 효율적으로 운영하고 싶습니다. 운영 도구를 효율적으로 사용하고 싶습니다.

이를 염두에두고 지속적인 통합에 대해 더 많이 배우고 싶었지만 여기에는 여러 가지가있는 것 같습니다.

나는 실제로 내 작업 (IntelliJ, WebStorm ...)에서 Jetbrains 슈트와 함께 일하고 있으므로 계속 사용하고 싶었고 TeamCity를 사용하여 지속적인 통합을위한 많은 플러그인이있는 훌륭한 도구가되었습니다.

내 문제는 차이점이 무엇인지 모른다는 것입니다.

• 빌딩 자동화 (TeamCity는 이런 종류의 소프트웨어입니다) : 원격 VCS 리포지토리를 사용하여 애플리케이션을 구축 할 수 있다는 점을 잘 알고 있습니다. 그러나 그 주요 목표는 무엇입니까? 이 작업을 수행하는 동안 어떤 종류의 정보가 중요합니까? 사실, 나는 이미 내 소프트웨어가 로컬에 구축되어 있는지 아닌지를 알고 있으며 팀원들도 알고 있습니다. 그렇다면 자동화를 배포하지 않고 사용하는 목표는 무엇입니까?

• 자동화 배포 (TeamCity는 쉽게 수행하지 못하는 것 같습니다)

• 지속적인 통합 (위의 두 가지를 결합한 것으로 보입니다)
• 지속적인 전달 (정확히 무엇입니까? 지속적인 통합과 다른 이유는 무엇입니까?)

좀 더 이해하도록 도와 줄 수 있습니까?

Wikipedia는 대부분의 용어에 대한 요약을 제공합니다. 여기에 내가 취할 수있는 것들이 있습니다.

• 빌드 자동화 는 수동으로 컴파일러를 호출하는 대신 소프트웨어 빌드 방식을 자동화합니다. 이는 Make 또는 Ant 와 같은 도구를 통해 수행됩니다 .

• 배포 자동화는 빌드 된 소프트웨어를 사용하여 테스트 또는 프로덕션 시스템에 배포 또는 설치합니다.

• 지속적인 통합 이란 개발자가 코드를 체크인 할 때 자동화 된 프로세스가 소프트웨어를 지속적 으로 구축 하고 코드가 여전히 작동하는지 확인하기 위해 단위 테스트를 실행 하는 것을 의미 합니다. 예를 들어 15 ~ 30 분마다 서버가 깨어나 VCS 에서 새 체크인을 검색 한 다음 변경 사항이있을 경우 프로젝트를 업데이트하고 빌드 할 수 있습니다. 컴파일 단계를 수행하는 것 외에도 자동화 된 단위 테스트 및 코드 품질 검사 를 실행할 수있는 좋은 기회 입니다.

• 지속적인 제공 은 소프트웨어 빌드가 테스트 시스템에 배포되고 선택적으로 테스트가 수행되고 보고서가 생성되는 이전의 모든 개념의 조합입니다.

최소한 빌드 자동화, 즉 일종의 빌드 스크립트가 있어야 합니다. 이를 통해 하나의 버튼을 클릭하거나 하나의 명령을 실행하여 프로젝트를 빌드 할 수 있습니다. 이것의 장점은 수동으로 실행하는 단계에서 발생하는 오류를 줄이는 것입니다. 복잡한 빌드 환경에는 코드 생성 ( 구성에서 DAO 생각 , JAXB 와 같은 인터페이스 코드 생각 ), 코드 컴파일, 코드 패키징, 메타 데이터 사용자 정의 등이 포함됩니다. 빌드 스크립트를 실행하고 도구를 사용하여 실행합니까? 오류를 줄이고 일관성을 제공합니다.

다음은 CI입니다. 이것은 실제로 는 좋지만 반드시 필요한 것은 아닙니다. 빌드 문제를 조기에 식별하는 데 도움이됩니다. 하루 종일 여러 명의 개발자가 코드를 체크인하고 자신의 작업 공간을 지속적으로 동기화하지 않으면 변경 사항이 서로 간섭 할 위험이 있습니다. 버전 제어 충돌이 아닌 정적 코드 오류를 구체적으로 언급하고 있습니다. CI 빌드 서버는이 위험을 완화시킵니다.

마지막으로 배포 단계가 있습니다. 여기서 아이디어는 수동으로 소프트웨어를 배포 할 때 시간을 절약하고 오류를 줄이는 것입니다. 빌드 자동화와 마찬가지로 소프트웨어 배포를 망칠 수있는 100 가지 방법이 있습니다. 나는 내일 현장에 오는 고객들을 위해 기능적인 시스템이 필요할 때 수동 배포 문제를 해결하기 위해 개인적으로 사무실에 늦게 머물 렀습니다. 여러 시스템을 소개합니다 더 많은 위험을 자동화 : 대신 하나 개의 시스템이 가능하게 충돌 또는 이상한 오류를 가지고, 우리가 지금 가지고있는 여러잘못 될 수있는 시스템. 그러나 이러한 위험은 누군가가 체크리스트에서 한 단계를 잃어 버리거나 잘못된 명령을 내리고 배치를 망치는 것보다 훨씬 낮습니다. 운이 좋으면 DB 백업을 복원하고 다시 시작할 수 있습니다. 운이 좋지 않으면 오류로 인해 시스템이 제대로 작동하지 않을 수 있습니다. 소프트웨어 결함입니까? 기술자가 구성을 올바르게 설정하지 않았습니까? 진단하는 데 시간이 걸리고 프로세스를 자동화하는 데 소요될 수있는 시간과 시간이 필요하지 않습니다.

• 지속적인 통합 은 모든 개발자 변경 사항을 하루에 여러 번 공유 된 메인 라인으로 병합하는 방법입니다. 이 관행은 이제 너무나 보편적 인 것으로 보이지는 않지만 중요하지는 않지만 전통적으로 팀은 몇 주 또는 몇 달 동안 격리 된 상태에서 소프트웨어 작업을 수행합니다. 별도의 작업 스트림이 병합 될 때 결과는 "통합 지옥"이었습니다. Continuous Integration은 일반적으로 공유 메인 라인의 자동화 된 빌드와 함께 사용하여 문제를 조기에 발견하지만 DevOps보다는 커밋과 개발자 워크 플로우에 대한 정보가 더 많습니다.

• 자동화 된 빌드는 빌드가 로컬로 전달 될 수 있지만 빌드 서버에서 실패 할 수있는 문제를 선택하는 데 유용합니다 (예 : 파일 체크인을 잊어 버렸습니다. 빌드 서버의 종속성이 일치하지 않음). 빌드 서버가 이러한 문제를 감지하게되면 팀원이하기 전에 문제를 해결할 수 있습니다.

• Continuous Delivery는 소프트웨어를 지속적으로 배포, 실행 및 테스트합니다. 자동화 된 빌드는 소프트웨어가 실제로 빌드되고 단위 테스트가 통과되는 것을 보장하지만 배포 스크립트가 여전히 작동하거나 소프트웨어가 실제로 엔드 투 엔드를 실행한다는 것을 의미하지는 않습니다. Continuous Delivery의 목표는 메인 라인이 프로덕션에 배치하기에 적합한 상태를 유지하도록 일련의 점검을하는 것입니다.

• Continuous Deployment는 다음 논리적 단계입니다. Continuous Delivery 파이프 라인을 통과 한 모든 커밋을 자동으로 배포합니다. 이 방법에는 몇 가지 이점이 있지만 여기서 중요한 것은 작고 빈번한 커밋이 덜 위험하다는 것입니다.

자세한 내용은이 책을 읽는 것이 좋습니다.

• 지속적인 제공 : 빌드, 테스트 및 배포 자동화를 통한 안정적인 소프트웨어 릴리스

많은 빌드 도구와 같은 Teamcity는 다양한 작업을 수행 할 수있는 중앙 앱입니다. 여기에는 CI 빌드, 정식 릴리스 빌드와 같은 빌드 수행이 포함되며 배포를 수행 할 수 있습니다. 팀 시티를 사용하여 솔루션 파일에서 ant 또는 nant를 호출하여 msbuild를 실행하는 경우 배포를 수행 할 nant 스크립트를 호출 할 수도 있습니다. 약간의 스크립팅이 필요할 수 있지만 어렵지 않습니다.

우리는 전체 CI, 데이터베이스 CI에 팀 시티와 대나무를 사용하고 INTegration 환경에 배포합니다. 그런 다음 전체 릴리스 빌드 및 자동으로 DB 마이그레이션 스크립트 작성에 teamcity를 사용합니다. 이들은 nant 스크립트를 호출하는 teamcity 작업을 통해 SVN에 체크인됩니다. 배포의 경우 teamcity를 사용하여 nant를 호출하여 배포 작업을 수행합니다. 이는 teamcity 에이전트가 teamcity 서버와 통신하고 에이전트가 DMZ 위치의 서버 중 하나에 존재하여 방화벽 등을 넘어 코드를 이동시키는 데 도움이되기 때문에 효과적입니다. 따라서 전체 시나리오를 처리하기 위해 teamcity 또는 bamboo 만 있으면됩니다. .