반응형
IT에서 협업이란?
- Silo 극복, 비즈니스 효율, 커뮤니케이션 목적으로 활용
- IT 환경의 빠른 변화 > 대규모 N/W, OSS
- 요구사항 등에 대하나 유연한 대처
- 측정 가능한 Metric & Monitoring
- 지속적 Delivery
- Infra 활용 극대화
CI/CD (Continuous Integration/Continuous Delivery)
- 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법
(버전 관리 & 형상관리가 제대로 되어 있을 때 성립)
개발 협업을 위한 도구 | |
GitHub | - 대표적인 코드 저장소 서비스 - 코드뿐만 아니라 이슈 트래커, 공동 개발, 위키 등 개발과 관련된 다양한 활동 가능 |
JIRA | - 프로젝트 관리 툴로 이슈 중심의 프로젝트 관리와 협업 가능 - 개발자로부터 디자이너, 비즈니스 멤버까지 폭넓게 사용 - 이슈 관리가 용이하며 이를 개인 단위 혹은 팀 단위에서 처리 및 관리가 가능하도록 설계 |
SourceTree | 깃 |
JANDI | - 업무 커뮤니케이션 플랫폼 |
버전(형상)관리 - Source Configuration Management
- SDLC 상 코드 및 산출물의 체계적 관리를 위해 가시성, 추적성, 무결성을 확보하는 품질 보증 기법

버전관리 시스템이 갖춰야 할 요소 | |
변경점 관리 | - 여러 사용자들이 release한 시점을 관리 |
버전 관리 | - 특정 시점에 Tag를 달아 버전 표시 - 브랜치(branch)를 여러 버전을 개발 가능 |
백업 & 복구 | - 버전관리를 통해 복구 또는 다른 곳으로 백업을 가능케 함 |
협업 | - 개별 사용자의 수정사항을 쉽게 공유 |
로컬 버전관리시스템
- 간단한 데이터베이스만으로도 구현 가능
- 단순하고 개인적인 프로젝트에 적합 (협업에서는 사용하기 힘듦)
- SPOF에 취약하며 내부 정보 관리가 중요
- RCS
- 형상이 로컬에서 관리되는 초기 형태의 버전 관리 시스템
중앙집중식 버전관리시스템
- 다수 인원이 작업하는 경우 생기는 문제들을 해결하기 위해 개발된 도구
- 서버에 최종본 한 벌이 존재
- 사용자들은 이중 수정을 원하는 파일만 로컬에 받아 수정 후 서버에 올리게 됨
- 사용자 관리가 용이하며 중앙의 vSC 하나만 관리하면 됨
- 로컬 VCS와 마찬가지로 SPOF 존재
- 협업의 규모가 커지면 수정 충돌 문제 발생 가능
- Subversion(SVN)
- 2000년에 개발되어 Apache 재단 소유로 넘어옴
- 사용성이 좋으나 대형 프로젝트에 부적합 - CVS
- 1990년대에 개발되어 널리 쓰였던 도구로 복잡해지는 개발환경에 부적합하여 지금은 쓰이지 않음
분산 버전관리 시스템
- 파일을 저장하는 서버가 있는 것은 중앙집중식과 동일하나 프로젝트에 관련된 저장소와 히스토리 전체가 로컬에 존재
- 저장소와 히스토리를 전부 복제
- 클라이언트가 단순히 최신 파일의 마지막 스냅샷을 checkout하지 않음
- 서버에 문제가 생겨도 복구가 가능하며 clone은 모든 데이터를 가짐
- 원격저장소가 존재하며 다양한 그룹과 협업 가능
- Git
- 현재 VCS의 최고 점유율을 가진 도구로 다양한 IDE Tool이 내장

- 2005년에 리누스 토르발스에 의해 개발된 분산 버전관리 시스템
장점
- 분산형
- 인터넷 연결이 되지 않은 곳에서도 개발 진행 가능
- 분산 버전관리이기 때문에 중앙 저장소가 삭제되어도 원상복구 가능 - 대규모 프로젝트
- 각각의 개발자가 Branch에서 개발한 뒤, 본 프로그램에 합치는 merge 방식을 통한 병렬 개발 가능

Git 기본 용어
Repository | - 저장소는 히스토리, 태그, 소스의 가지치기 또는 branch에 따라 버전을 저장 - 작업자가 변경한 모든 히스토리를 확인 가능 |
|
Working Tree | - 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점 (흔히 말하는 폴더 구조) | |
Index | - Commit을 실행하기 전의 저장소와 Working Tree 사이에 존재하는 공감 (Staging 처리, Commit하고자 하는 파일만 등록) |
|
Branch | - 가지 또는 분기점, 작업을 할 때 현재 상태를 복사하여 Branch에서 작업을 한 후 완전하다 싶을 때 Merge를 하여 작업함 |
|
통합 Branch | - 언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치 - 늘 안정적인 상태를 유지하는 것이 중요 (통합 Branch는 무조건 Master라고 볼 수 없음) |
|
토픽 Branch | - 기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치 - 하나의 목적을 갖고 별도로 만든 Branch 개념 |
|
Head | - 현재 작업 중인 Branch를 가리킴 | |
Staging Area | - 저장소에 커밋하기 전에 커밋을 준비하는 위치 | |
로컬 저장소 | - 내 컴퓨터에 있는 로컬 저장소 |
Branch 종류
구분 | 브랜치명 | 설명 |
메인 브랜치 | master | - 제품으로 출시될 수 잇는 브랜치 - 배포(Release) 이력을 관리하기 위해 사용, 배포 가능한 상태만을 관리 |
develop | - 다음 출시 버전을 개발하는 브랜치 - 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적 상태일 때 master에 병합 |
|
보조 브랜치 | feature | - 기능 개발 브랜치 - 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기 - 기본적으로 공유할 필요가 없기 때문에 자신의 로컬에서 관리 |
release | - 이번 출시 버전을 준비하는 브랜치 - 배포를 위한 전용 브랜치 사용, 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속 할 수 있음 |
|
hotfix | 출시 버전에서 발생한 버그를 수정하는 브랜치 |
구분 | Git | SVN |
업로드 | 로컬저장소 저장 후 서버 업로드 | 중앙서버 업로드 |
충돌 가능성 | Branch와 Merge를 통해 충돌 가능성 낮음 | 동시 업로드 시 충돌 가능성 多 |
네트워크 | 작업은 로컬에서, 업로드만 네트워크 사용 | 모든 작업에 네트워크 사용 |
히스토리 | 히스토리 관리 기능이 우수 | 상대적으로 약함 |
반응형
'교육' 카테고리의 다른 글
Git & GitHub 실무 활용 (GitHub 용어 정리) (0) | 2023.05.27 |
---|---|
Git & GitHub 실무 활용 (Git 설치 및 용어 정리) (0) | 2023.05.26 |
비즈니스 성장을 위한 AI 트랜스포메이션 (SK 생성형 AI 토탈 서비스 런칭) 웨비나 (0) | 2023.05.17 |
교육 일정 관리 프로젝트 (계획 수립 단계) (0) | 2023.05.12 |
교육 일정 관리 프로젝트 (Nexacro 실습) (1) | 2023.05.12 |