MISTERY

젠킨스(Jenkins)를 이용한 지속적 통합(CI:Continuous Integration)
(2) 젠킨스씨가 있는 개발풍경


젠킨스에 대한 두번째 포스팅으로 오늘은 젠킨스가 실제 프로젝트에서 어떤 형태로 사용될 수 있는지 살펴 보고자 한다.

젠킨스씨가 있는 개발풍경


하루 24시간이 모자르신 젠킨스씨

형상관리 툴과의 연동

젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적 이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모두 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었는데 이를 nightly-build라 한다. Fire Fox와 같은 많은 오픈소스 프로젝트들은 정식 배포 버전과 별도로 nightly-build에서 생성된 바이너리를  함께 배포함으로서 오픈 베타테스트 또한 지속적으로 수행 할 수 있게  되었다.

젠킨스는 정기적인 빌드에서 한반 나아가 서브버전, Git와 같은 버전관리 툴과 연동하여 소스의 커밋을 감지하면 자동적으로  자동화 테스트가 포함된 빌드가 작동되도록 설정 할 수 있다.



물론 개발도중의 프로젝트에서 커밋은 매우 빈번히 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라  큐잉되어 자신이 실행될 차례를 기다리게 된다.

코드의 변경과 함께 이뤄지는 이같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.


  • 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
  • 자동화 테스트 수행
  • 정적 코드 분석에 의한 코딩 규약 준수여부 체크
  • 프로파일링 툴을 이용한 소스 변경에 따른 성능변화 감시
  • 결합 테스트 환경에대한 배포작업

이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이선과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.

각종 배치 작업의 간략화 

프로젝트 기간중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, 디플로이 작업과 같은 단순 작업에 시간과 노력을 빼았기는 경우가 빈번하다.
데이터베이스의 구축, 어플리케이션 서버에의 디플로이,  라이브러리 릴리즈와 같이 이전에 커맨드 라인 인터페이스로 실행되던 작업들이 젠킨스 덕분에 미려한 웹인터페이스로 손쉽게 가능해 지게 되었다.

젠킨스씨는 거들뿐

이와같이 다양한 작업들을 손쉽게 처리해 주지만 테스트를 만들고 빌드 전략을 세우는 등의 작업은 여전히 개발자의 몫으로 남아 있다. 젠킨스가 진정으로 프로젝트에 도움이 되기 위해서는 다음과 같은 작업이 반드시 함께 이루어 져야 한다.

Build 자동화의 확립: 빌드 툴의 경우 Java는 이미 Maven이 대세로 자리잡았다. 물론 Ant도 훌륭한 기능들을 많이 갖추고 있지만 플러그인의 편리함은 Maven을 따라잡지 못한다. 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 Jenkins를 사용하지 않을 이유가 하나도 없다.

자동화 테스트: 자동화 테스트야 말로 젠킨스를 사용해야 하는 이유중 으뜸이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git와 같은 버전관리 시스템관 연동하여 코드변경을 감지하고 자동화 테스트를 수행해 줌 으로서 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.
무엇보다 중요한것은 이러한 안전망이 제공해 주는 안심감이야 말로 개발자들이 악취나는 코드를 리팩토링을 통해 적극적으로 제거 할 수 있게 해 주는 든든한 버팀목이 된다는 점이다.


제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스씨를 만나게 된다.

테스트 커버리지: 젠킨스는 자동화 테스트 실시와 더불어 테스트 커버리지도 리포팅을 해 준다. 개인적으로 테스트 커버리지가 품질에 대해서 기여하는 부분에 대해서는 회의적인 입장이다. 결국 자동화 테스트의 작성 자체는 프로그램 사양에 대한 개발자 심도있는 고찰을 기반으로 하는데 커버리지 라고 하는 일괄적인 기준으로 제약을 가하게 되면 테스트가 본래의 의미를 잃어버린 커버리지를 달성하기 위한 테스트가 만들어지기 쉽기 때문이다.
젠킨스에서는 다양한 형태로 클러스터링을 지원하는데, 자동화 테스트가 충실하게 작성된 프로젝트라면 테스트에 상당한 컴퓨팅 파워가 투입되어야 하기 때문이다. 

코드 표준 준수여부 검사: 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수여부의 검사나 정적 분석을 통한 코드 품질  빌드 내부에서 수행하는 것으로서 기술적 부채의 감소에도 크게 기여한다.

빌드 파이프라인 구성: 2개 이상의 모듈로 구성되는 프로젝트의 경우 당연하게도 레이어드 아키텍처가 적용되어 있을터이고 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들자면 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다. 이러한 파이프라인의 구성은 선형뿐만 아니라 간단한 스크립트를 통해 매우 복잡한 제어 까지도 가능하다. 

Build Pipeline Plugin을 이용하면 논리 구조를 가진 파이프라인도 웹 인터페이스를 통해 간단히 만들 수 있다.




학교에서 선배가 젠킨스를 추천해줬다.. 처음 본것 같은데..

그래도 마틴파울러는 안다 ㅋㅋ 다시 열정으로 달려보자..






출처 : http://www.moreagile.net/2014/01/jenkins-cicontinuous-integration-2.html








신고

Comment +2

사용자가 값 변경시 페이지에 바로 반영해야할경우

postback 옵션으로 페이지를 새로고침하는데
이게 페이지를 새로 불러오는 개념이라 스크롤 위치가 항상 맨위로 돌아가버린다.

페이지 내용이 별로 없으면 상관이 없는데 페이지 길이가 상당히 긴 경우에는 
사용자 입장에서 정말로 귀찮은 일이 아닐수 없다.

해결법은 해당 aspx파일의 맨위에 아래 구문을 넣어두면 된다.

<%@ Page Language="C#" AutoEventWireup="true" ... MaintainScrollPositionOnPostback="true" %>  

해결끝....?

이라고생각했지만 아무리해도 크롬에서는 작동이안되는데...
검색결과 찾아낸 해결방법은 아래와같다.

To support the scroll position capability in Chrome, you need to follow the steps given below:
  1. Add the following line of code in the Page_Load of the page for which you want to maintain the scroll position.
    this.MaintainScrollPositionOnPostBack = true;
  2. Right click on the project.
  3. Click on “Add” -> “Add New Item”.
  4. In the “Add New Item” window, select “Browser File” and click “Add”.
  5. Application will ask you to place this file in “App_Browsers” folder, click “Yes”
  6. Now add the capability of maintaining the scroll position as follows:
    <browsers>
    <browser refID="Safari1Plus">
    <capabilities>
    <capability name="supportsMaintainScrollPositionOnPostback" value="true" />
    </capabilities>
    </browser>
    </browsers>

 

 

 

 

 

 

 

 

 

 출처 : http://egloos.zum.com/bangley/v/5753731
            http://www.codeproject.com/Tips/207917/Maintain-Scroll-Position-Problem-fix-for-Chrome
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

신고

Comment +0

1. collectd 설치

“# yum install collectd*


2. 설정

“# vi /etc/httpd/conf.d/collectd.conf

Allow from 127.0.0.1 을 Allow from All 로 수정


3. 접속

“http://연결도메인/collectd/bin/index.cgi


4. collectd 부가설정

“# vi /etc/collectd.conf












출처 : 

1. http://www.xpressengine.com/index.php?mid=tiptech_server&category=19377627&document_srl=22708727

2. https://collectd.org/wiki/index.php/First_steps

3. http://blog.naver.com/i0262/60207306050










신고

Comment +0

스케줄링의 개요

시스템의 여러자원을 해당 프로세스에 할당하는 작업을 의미

 

프로세스 스케줄링

프로세스가 실행되기 위해 CPU를 할당하는 시기와 특정 프로세스를 지정하는 작업

프로세스 스케줄러 : 하나의 프로세스를 준비상태에서 실행상태로 전이시킴

 

비선점형 스케줄링

이미 할당된 CPU를 다른 프로세스가 강제로 빼앗아 사용할 수 없는 스케줄링 기법(대화식 시스템에는 부적합)

FIFO(First In First Out) : 큐, 순서대로 처리

SJF(Shortest Job First) : 실행 시간이 길면 계속 밀림

HRN(Highest Response-ratio Next ≒ Aging 기법) : 우선순위 계산식-대기시간도 고려

대기시간 + 서비스 시간

         서비스 시간

기한부(Deadline) : 제한시간을 줌

우선순위(Priority) : 순위를 매김

 

선점형 스케줄링

하나의 프로세스가 CPU를 할당받아 실행하고 있을 때 우선순위가 높은 다른 프로세스가 CPU를 강제로 빼앗아 사용할 수 있는 스케줄링 기법(대화식 시스템에는 적합)

SRT(Shortest Remaining Time) : 처리되고 남은 시간으로 판단

RR(Round Robin) : 시분할 시스템을 위해 고안된 방식으로 FIFO, 할당된 시간이 클 경우 FIFO기법과 같아짐, 할당된 시간이 작을 경우 문맥교환 및 오버헤드가 자주 발생

MLQ(Multi-Level Queue) : 레벨별로 프로세스를 나눔, 상위는 SYSTEM,  중간은 대화형, 하위 일괄작업

MFQ(Multi-level Feedback Queue) : 레벨별로 프로세스를 나누는데 First In First Out방식과 Round Robin 방식을 더한 방식, 상위와 중간은 FIFO, 하위는 RR방식으로 처리

 

스케줄링의 목적

i) 처리율 증가

ii) CPU 이용률 증가

iii) 오버헤드의 최소화

iv) 응답시간의 최소화

v) 반환시간의 최소화

vi) 대기시간의 최소화

 

 

 

 

 

 

 

 

출처 : http://blog.naver.com/ovter?Redirect=Log&logNo=206405689

 

 

 

 

 

 

 

신고

Comment +0

4. 프로세스 스케줄링


가. 프로세스 스케줄링의 목적
- CPU 이용률을 극대화 하기 위해서 항상 어떤 프로세스가 실행되도록, 프로세스 사이에서 CPU를 교체
- CPU 스케줄러 : CPU에서 수행 가능한 여러 프로세스들 중에서 하나의 프로세스 선택

나. 스케줄링 큐
1) 작업 큐(Job Queue) : 시스템 안에 모든 프로세스
2) 준비완료 큐 ( Ready Queue)
- main memory에 존재하며, 준비완료 상태에서 실행 대기 프로세스
- linked list, 각 프로세스PCB는 준비완료큐의 다음 프로세스 포인터 가르킴
3) 장치 큐(Device Queue) : I/O 장치의 동작을 대기하는 프로세스 리스트

 다. 스케줄러


1) 장기 스케줄러 (작업 스케줄러)
- 디스크 공간에 제출된 프로세스들을 선택하여 주기억장치로 적재
- 최상 성능의 시스템은 I/O bound와 CPU bound의 적절한 혼합이 필요
- 다중 프로그래밍(메모리에 있는 프로세스들의 수) 제어

2) 단기 스케쥴러(CPU 스케쥴러)
- 실행 준비가 되어있는 프로세스들 중 한 프로세스를 선택하여 CPU 할당
- 스케쥴링은 프로세스간 Context Switching이 일어나는 것

3) 중기 스케줄러
- 메모리에서 프로세스들을 제거하여, 다중 프로그래밍의 정도 완화
- 이 후 필요시 다시 메모리로 불러와서 중단 지점 부터 실행 재개(swapping)



4) 프로세스 유형

- I/O 중심 프로세스(I/O bound) : CPU 연산 보다 입/출력 수행에 더 많은 시간 소비
- CPU 중심 프로세스(CPU bound ) : 연산에 더 많은 시간 소비

라. 문맥교환 (Context Switching)

- CPU가 다른 프로세스로 교체 실행 하는 것.
- context : 프로세스의 PCB
- CPU를 다른 프로세스로 넘겨주기 위해서 지금까지의 프로세스 상태를 보관하고 새로운 프로세스의 보관된 상태를 다시 적재하는 작업
-시스템측면에서 부담이 되며 성능 병목현상을 초래, 회피방법이 thread구조임

 

 

 

 

 

 

출처 : http://i-bada.blogspot.kr/2012/04/blog-post_4837.html

 

 

 

 

 

 

 

신고

Comment +0

티스토리 툴바