GitHub Actions 엔터프라이즈 마이그레이션에 대한 정보
엔터프라이즈를 GitHub Actions 기존 시스템에서 마이그레이션하려면 마이그레이션을 계획하고, 마이그레이션을 완료하고, 기존 시스템을 사용 중지할 수 있습니다.
이 가이드에서는 마이그레이션에 대한 구체적인 고려 사항을 다룹니다. 추가 정보를 위해 GitHub Actions를 귀하의 기업에 도입하는 것에 관한 엔터프라이즈에 GitHub Actions 소개을 참조하세요.
마이그레이션 계획
엔터프라이즈 GitHub Actions마이그레이션을 시작하기 전에 마이그레이션할 워크플로와 마이그레이션이 팀에 미치는 영향을 파악한 다음 마이그레이션을 완료하는 방법과 시기를 계획해야 합니다.
마이그레이션 전문가 활용
GitHub은 마이그레이션에 도움을 줄 수 있으며, GitHub Professional Services을(를) 구매해서 혜택을 받을 수도 있습니다. 자세한 내용은 전담 담당자에게 문의하세요 [GitHub의 영업 팀](https://github.com/enterprise/contact).
마이그레이션 대상 식별 및 인벤토리 작성
마이그레이션을 하기 전에, 기존 시스템에서 엔터프라이즈가 사용 중인 워크플로우를 완전히 이해하고 있어야 합니다.
먼저, 엔터프라이즈 내에서 기존 빌드 및 릴리스 워크플로의 인벤토리를 만들어 현재 사용 중인 워크플로, 마이그레이션해야 하는 워크플로 및 남아 있는 워크플로에 대한 정보를 수집합니다.
다음으로, 현재 공급자와 GitHub Actions의 차이점을 배우십시오. 이렇게 하면 각 워크플로를 마이그레이션하는 데 어려운 점과 엔터프라이즈에서 기능의 차이를 경험할 수 있는 위치를 평가하는 데 도움이 됩니다. 자세한 내용은 GitHub Actions로 마이그레이션을(를) 참조하세요.
이 정보를 사용하여 GitHub Actions로 마이그레이션할 수 있고 원하는 워크플로를 확인할 수 있습니다.
마이그레이션이 팀에 미치는 영향 확인
엔터프라이즈 내에서 사용 중인 도구를 변경하면 팀의 작동 방식에 영향을 줍니다. 기존 시스템에서 GitHub Actions 워크플로를 이동하여 개발자의 일상적인 작업에 어떤 영향을 미치는지 고려해야 합니다.
마이그레이션의 영향을 받을 프로세스, 통합 및 타사 도구를 식별하고 수행해야 하는 모든 업데이트에 대한 계획을 수립합니다.
마이그레이션이 규정 준수 문제에 어떤 영향을 미칠 수 있는지 고려합니다. 예를 들어, 기존 자격 증명 검사 및 보안 분석 도구가 GitHub Actions와 함께 작동하나요, 아니면 새 도구를 사용해야 할까요?
기존 시스템에서 게이트 및 점검 요소를 식별하고, 이를 GitHub Actions와 함께 구현할 수 있는지 확인하십시오.
마이그레이션 도구 식별 및 유효성 검사
자동화된 마이그레이션 도구는 엔터프라이즈 워크플로를 기존 시스템의 구문에서 필요한 GitHub Actions구문으로 변환할 수 있습니다. 타사 도구를 식별하거나 전담 담당자에게 문의하거나 GitHub의 영업 팀 제공할 수 있는 GitHub 도구에 대해 문의하세요. 예를 들어, 다양한 지원되는 서비스에서 GitHub Actions Importer을 사용하여 CI 파이프라인을 GitHub Actions로 계획하고, 범위를 지정하고, 마이그레이션할 수 있습니다. 자세한 내용은 GitHub Actions Importer를 사용하여 마이그레이션 자동화을(를) 참조하세요.
마이그레이션을 자동화하는 도구를 식별한 후 일부 테스트 워크플로에서 도구를 실행하고 결과가 예상대로 표시되는지 확인하여 도구의 유효성을 검사합니다.
자동화된 도구는 대부분의 워크플로를 마이그레이션할 수 있어야 하지만 최소 비율의 워크플로를 수동으로 다시 작성해야 할 수 있습니다. 완료해야 하는 수동 작업의 양을 예측합니다.
마이그레이션 접근 방식 결정
엔터프라이즈에 가장 적합한 마이그레이션 접근 방식을 결정합니다. 소규모 팀에서는 “완전 바꾸기(rip-and-replace)” 접근 방식을 사용하여 모든 워크플로를 한 번에 마이그레이션할 수 있습니다. 대기업의 경우 반복 접근 방식이 더 현실적일 수 있습니다. 중앙 기구가 전체 마이그레이션을 관리하도록 선택하거나 자체 워크플로를 마이그레이션하여 개별 팀에 셀프 서비스로 관리하도록 요청할 수 있습니다.
활성 관리와 셀프 서비스를 결합하는 반복 접근 방식을 사용하는 것이 좋습니다. 내부 챔피언 역할을 할 수 있는 소규모 얼리어답터 그룹으로 시작합니다. 비즈니스의 범위를 나타낼 수 있을 만큼 포괄적인 소수의 워크플로를 식별합니다. 얼리 어답터와 협력하여 필요에 따라 반복적으로 해당 워크플로를 GitHub Actions로 마이그레이션합니다. 이렇게 하면 다른 팀에도 워크플로를 마이그레이션할 수 있다는 확신을 줄 수 있습니다.
그런 다음, 조직 전체에 GitHub Actions을(를) 이용할 수 있도록 하세요. 이러한 팀이 워크플로를 GitHub Actions로 마이그레이션하는 데 필요한 리소스를 제공하고, 기존 시스템의 사용 중지 시점을 팀에 알리십시오.
마지막으로 이전 시스템을 사용하고 있는 모든 팀에 특정 기간 내에 마이그레이션을 완료하도록 알릴 수 있습니다. 다른 팀의 성공을 언급하면서 마이그레이션이 가능하고 바람직하다고 안심시킬 수 있습니다.
마이그레이션 일정 정의
마이그레이션 방법을 결정한 후 각 팀이 워크플로를 마이그레이션할 시기를 간략하게 설명하는 일정을 작성합니다 GitHub Actions.
먼저 마이그레이션을 완료하고자 하는 날짜를 결정합니다. 예를 들어 현재 공급자와의 계약이 종료되는 시점까지 마이그레이션을 완료하도록 계획할 수 있습니다.
그런 다음 팀과 협력하여 팀 목표 저하 없이 마감일을 충족하는 일정을 만듭니다. 마이그레이션을 요청하려고 하는 개별 팀의 비즈니스의 주기와 워크로드를 확인합니다. 각 팀과 협력하여 제공 일정을 파악하고 팀의 제공 능력에 영향을 주지 않으면서 워크플로를 한 번에 마이그레이션할 수 있는 계획을 수립합니다.
GitHub Actions으로 마이그레이션하는 중입니다.
마이그레이션을 시작할 준비가 되면, 기존 워크플로를 GitHub Actions로 변환하기 위해 위에서 계획한 자동화된 도구와 수동 다시 쓰기를 사용하세요.
또한 아티팩트를 보관하도록 스크립팅된 프로세스를 작성하여 기존 시스템에서 이전 빌드 아티팩트도 유지 관리할 수 있습니다.
기존 시스템 사용 중지
마이그레이션이 완료되면 기존 시스템의 사용 중지를 고려할 수 있습니다.
개발자를 위한 환경에 문제가 발생하지 않도록 GitHub Actions 구성이 안정적인지 확인하는 동안, 두 시스템을 일정 기간 동안 동시에 실행할 것을 권장합니다.
결국에는 이전 시스템을 해제 및 종료하고, 엔터프라이즈 내의 누구도 이전 시스템을 다시 설정하지 않도록 하세요.