<div id="readability-page-1" class="page"><div>
        <article>
          <h2 id="챕터1">챕터1</h2>

<p>변경할 때마다 소프트웨어 빌드하기1</p>

<blockquote>
  <p>먼저 기초부터 통달하라 - 래리 버드</p>
</blockquote>

<ul>
  <li>매일 사과 하나를 먹어라</li>
</ul>

<h2 id="변경할-때마다-소프트웨어를-빌드하기">변경할 때마다 소프트웨어를 빌드하기</h2>

<p><a href="https://www.youtube.com/watch?v=L1dtkLeIz-M">https://www.youtube.com/watch?v=L1dtkLeIz-M</a></p>

<ul>
  <li>코드 커밋 → 저장소에서 변경 내역 감지 및 빌드 / 통합 → 변경내역 전달 → CI 서버는 계속 변경사항 체크</li>
</ul>

<h2 id="개발자">개발자</h2>

<ul>
  <li>자주 빌드하여 문제를 빨리 찾아내기
    <ul>
      <li>코딩표준 준수 여부</li>
      <li>자동화된 테스트 적용 얼마나 (커버리지)</li>
      <li>최근이 변경사항이 테스트 통과?</li>
      <li>성능 요구사항 준수?</li>
      <li>마지막 배포 문제 없음?</li>
    </ul>
  </li>
</ul>

<h2 id="버전-관리-저장소">버전 관리 저장소</h2>

<ul>
  <li>저장소는 프로젝트의 표준이 되어야</li>
</ul>

<h2 id="지속적인-통합-서버">지속적인 통합 서버</h2>

<ul>
  <li>저장소의 변경사항을 감지</li>
  <li>자동 테스트 및 빌드</li>
  <li>대시보드 제공</li>
</ul>

<h2 id="빌드-스크립트">빌드 스크립트</h2>

<ul>
  <li>빌드 스크립트 사용 (수동 빌드 대체)</li>
</ul>

<h2 id="피드백-메커니즘">피드백 메커니즘</h2>

<ul>
  <li>테스트 및 빌드에 문제가 있을 경우 피드백을 빨리 받기</li>
  <li>이메일, 문자, RSS 등 (현대에는 무엇이 있을까? 슬랙?)</li>
</ul>

<h2 id="통합-빌드-머신">통합 빌드 머신</h2>

<ul>
  <li>프로젝트를 빌드하는 것이 유일한 목적인 머신</li>
</ul>

<h2 id="지속적인-통합의-특징">지속적인 통합의 특징</h2>

<ul>
  <li>버전 관리 저장소로의 연결</li>
  <li>빌드 스크립트</li>
  <li>몇 종류의 피드백 메커니즘</li>
  <li>소스코드 변경 내역을 통합하기 위한 프로세스</li>
</ul>

<h2 id="소스-코드-컴파일">소스 코드 컴파일</h2>

<ul>
  <li>통합 ↔ 소스코드 컴파일</li>
  <li>검사 → 테스트 → 소스코드 컴파일 → DB 통합 → 배포</li>
</ul>

<h2 id="데이터베이스-통합">데이터베이스 통합</h2>

<ul>
  <li>CI 와 Database integration 은 별개의 임무가 아님</li>
  <li>데이터베이스 연결, 조작, 스크립트 등이 고려되어야</li>
</ul>

<h2 id="테스트">테스트</h2>

<ul>
  <li>단위 테스트</li>
  <li>회귀 테스트</li>
</ul>

<h2 id="검사-inspection">검사 (Inspection)</h2>

<ul>
  <li>lint</li>
  <li>coding convention</li>
</ul>

<h2 id="배포">배포</h2>

<ul>
  <li>저장소 → 소스코드 체크아웃 → 빌드 → 테스트 및 검사 → 릴리즈 태깅 → 배포</li>
</ul>

<h2 id="문서화와-피드백">문서화와 피드백</h2>

<ul>
  <li>간결하고 명확한 코드가 최고의 문서</li>
  <li>Javadoc 등을 이용할 수 있음</li>
  <li>좋은 CI 의 핵심 특징은 속도</li>
  <li>정수는 개발자와 프로젝트 이해관계자 들에게 시의 적절하게 피드백 제공하는 것</li>
</ul>

<h2 id="챕터1-요약">챕터1 요약</h2>

<h3 id="인상">인상</h3>

<ul>
  <li>2008년에도 이런 아이디어가 있었다니.. 이때 난 뭐했지? 수동 서버 관리, 수동 백업, 수동 설치, 아이언맨</li>
  <li>이제 손쉬운 CI 툴이 있다. (gitlab, jenkins)</li>
  <li>소프트웨어와 DB 를 분리하지 말자</li>
</ul>

<h3 id="적용">적용</h3>

<ul>
  <li>10년 전 이러한 회사를 피해라? 버전관리 X</li>
  <li>지금은 지속적 배포, 회귀 테스트를 하고 있는가</li>
  <li>나는 변경할 때마다 빌드 하는가? FeConf 최수형님 영상의 그 느낌</li>
  <li>나의 개발환경 부터 CI 환경을 구성해보자</li>
  <li>나는 빠른 피드백이 가능한 지 점검해보자</li>
</ul>

<h3 id="회고">회고</h3>

<ul>
  <li>subversion 의 특성 상 저장소 푸시 이후 모든 과정이 시작. git 시대에는 달라야 하지 않을까</li>
</ul>

        </article>
      </div></div>

Orc’s WIKI

Orc Hwang

챕터1
변경할 때마다 소프트웨어 빌드하기1
먼저 기초부터 통달하라 - 래리 버드
매일 사과 하나를 먹어라
변경할 때마다 소프트웨어를 빌드하기
https://www.youtube.com/watch?v=L1dtkLeIz-M
코드 커밋 → 저장소에서 변경 내역 감지 및 빌드 / 통합 → 변경내역 전달 → CI 서버는 계속 변경사항 체크
개발자
자주 빌드하여 문제를 빨리 찾아내기
    
코딩표준 준수 여부
자동화된 테스트 적용 얼마나 (커버리지)
최근이 변경사항이 테스트 통과?
성능 요구사항 준수?
마지막 배포 문제 없음?
버전 관리 저장소
저장소는 프로젝트의 표준이 되어야
지속적인 통합 서버
저장소의 변경사항을 감지
자동 테스트 및 빌드
대시보드 제공
빌드 스크립트
빌드 스크립트 사용 (수동 빌드 대체)
피드백 메커니즘
테스트 및 빌드에 문제가 있을 경우 피드백을 빨리 받기
이메일, 문자, RSS 등 (현대에는 무엇이 있을까? 슬랙?)
통합 빌드 머신
프로젝트를 빌드하는 것이 유일한 목적인 머신
지속적인 통합의 특징
버전 관리 저장소로의 연결
빌드 스크립트
몇 종류의 피드백 메커니즘
소스코드 변경 내역을 통합하기 위한 프로세스
소스 코드 컴파일
통합 ↔ 소스코드 컴파일
검사 → 테스트 → 소스코드 컴파일 → DB 통합 → 배포
데이터베이스 통합
CI 와 Database integration 은 별개의 임무가 아님
데이터베이스 연결, 조작, 스크립트 등이 고려되어야
테스트
단위 테스트
회귀 테스트
검사 (Inspection)
lint
coding convention
배포
저장소 → 소스코드 체크아웃 → 빌드 → 테스트 및 검사 → 릴리즈 태깅 → 배포
문서화와 피드백
간결하고 명확한 코드가 최고의 문서
Javadoc 등을 이용할 수 있음
좋은 CI 의 핵심 특징은 속도
정수는 개발자와 프로젝트 이해관계자 들에게 시의 적절하게 피드백 제공하는 것
챕터1 요약
인상
2008년에도 이런 아이디어가 있었다니.. 이때 난 뭐했지? 수동 서버 관리, 수동 백업, 수동 설치, 아이언맨
이제 손쉬운 CI 툴이 있다. (gitlab, jenkins)
소프트웨어와 DB 를 분리하지 말자
적용
10년 전 이러한 회사를 피해라? 버전관리 X
지금은 지속적 배포, 회귀 테스트를 하고 있는가
나는 변경할 때마다 빌드 하는가? FeConf 최수형님 영상의 그 느낌
나의 개발환경 부터 CI 환경을 구성해보자
나는 빠른 피드백이 가능한 지 점검해보자
회고
subversion 의 특성 상 저장소 푸시 이후 모든 과정이 시작. git 시대에는 달라야 하지 않을까

지속적인 통합

댓글