728x90
반응형

오랜만에 10번째 에피소드입니다.

 

오늘은 일하면서 들어본 이상한 단어와 웃픈 에피소드에 대해서 말해보려고 합니다.

 


 

#1 아삭하게 해주세요.

 

제가 아웃소싱에서 일할 때였습니다.

 

고객사에서 급한 일감이 들어왔는데요.

 

언제까지 해야 하는지 물어봤는데

 

돌아온 대답은 "아삭하게"였습니다.

 

 

 

 

 

아삭하게? 뭘 아삭하게 하라는 거지?

어느 지역 사투리지??

 

야무지게 하라는 건가???

평소 사투리를 쓰시던 분이셔서 

 

어느지역 사투리인지 검색을 하다가

 

ASAP이라는 단어를 검색하고 

 

깊은 탄식을 내뱉은 적이 있습니다.

 

As Soon As Possible

 

빨리빨리 / 가능한 (최대한) 빨리라는 뜻입니다.

 

본래 1900년대 중반에 미군에서 사용되던 단어이고,

미군에서 퍼져 보통 사람들 사이에도 적잖게 사용되는 단어라고 합니다.

 

에이에스에피라고 하거나 글자를 그대로 읽어서 에이쌥, 아삽이라고 읽기도 합니다.

 

사람마다 다르게 말한다고는 하지만

 

 다만 영어권 원어민이 “아삽”이라고 읽는 경우는 없다고 합니다.

 

 

즉, 고객사에서는 가능한 빨리 업무를 수행해 달라고 했었지만

 

저는 야무지게 하라는 뜻으로 이해했던 그런 해프닝이 있었습니다!

 

 

#2 tl;dr로 말씀드릴게요~.

 

 

오늘 있었던 일입니다.

 

앱 배포 때 minor 한 버그를 포함시켜야 할지 말지를 논의하고 있었습니다.

 

제가 답변 내용을 크게 보지 않고

 

변경점이라는 포인트에 집중하다 보니 

 

어떤 의미인지 다시 여쭤봤습니다.

 

 

 

 

저는 tl;dr이

 

채팅으로 대화를 했기 때문에

 

한/영 키를 잘못 누른 상태에서 입력하신 줄 알았습니다.

 

 

역시나 검색해 보니 

 

아래와 같이 나왔습니다.

 

 

TL;DR

 

TL;DR, 풀어서 "too long; didn't read"(너무 길어서 읽지 않았다)라는 뜻입니다.

 

응답이 되는 어떠한 텍스트가 그 길이 때문에 무시되고 있다는 것을 말하는 인터넷 속어입니다.

 

인터넷에서 글이 지나치게 길어 이를 비난하거나 글을 줄이는 것을 조언하기 위해 쓰는

 

'생략'과 흡사한 단어입니다.

 

즉, 두괄식으로 요점만 말해주겠다.라고 이해할 수 있겠습니다.

 

TL; DR로 한번 표현을 해보면

 

TL;DR : 이번 배포에 포함시키지 말죠! 
(뒤의 내용~~~ )

 

이런 식으로 응용해 볼 수 있겠네요.

 


반응형

 

 

오늘은 일하면서 처음 들어본 생소한 단어에 대해서 

 

재밌게 풀어보는 시간을 가졌는데요

 

일할 때 처음 듣는 단어라고 너무 거부감을 가지거나 놀라지 마시고

 

적극 활용한다면 지식도 얻고 업무처리도 빠르게 할 수 있습니다.

 

그럼 이만!

 

 

728x90
반응형
728x90
반응형

가 업무 할 때 통하는 이야

 

야심차게 준비하였습니다. 내 소 기 !!!

 

내가 업무 할 때 소통하는 방법들을 정리해놓은 이야기를 펼쳐보려고 합니다.

 

Episode 별로 상황에 따라 소통했던 방법들을 재미로 보는 시간을 가지려고 합니다.

 

왜 이 코너를 준비했냐면,

 

QA 업무는 꼼꼼함? 높은 집중력? 다 좋습니다.

 

그러나 저는 개인적으로 높게 평가하는 능력이 하나 있습니다.

 

제가 면접관 업무를 볼 때나, 신규 인력 교육할 때 파악이 되는 능력 중 하나입니다.

 

바로 커뮤니케이션 능력인데요.

 

거의 5년 가까이 QA 업무를 하면서 느낀 점은 효과적인 커뮤니케이션은 

 

내 부족한 능력치를 채워줄 수 있다고 느꼈습니다.

 

그래서 실무에서는 제가 어떻게 커뮤니케이션을 하며 

 

임기응변을 진행했는지 공유해보려고 합니다.

 

일단은 경험의 기록의 목적으로 쓰려고 했으나

 

재미적인 요소도 있어야 할 것 같고요 또 교육적인 목적도 있어야 할 것 같습니다.

 

그리고 QA 업무를 지망하는 취준생들에게도 많은 도움이 되었으면 좋겠네요.

 

 다음 에피소드로 만나요~~

728x90
반응형
728x90
반응형

저번에 애자일 방법론의 간단한 개념에 포스팅을 했다면

 

이번에는 애자일을 더 알아보기 위해 책을 한권 추천하려고 한다.

 

 

애자일 프랙티스

밴캣 수브라마니암 , 앤디 헌트-

 

이 책은 애자일이 어떠한 것이고 전체적인 흐름과 소프트웨어 개발에 어떻게 적용되어 지는지에 대해 가볍게 읽기에 좋은 책이다.

 

중간중간 리뷰를 하자면 서문에 이러한 구절이 있다.

 

용기를 내서, ‘ 위험을 무릅쓰고서라도(Damn the Torpedoes)’ 올바른 선택을 지속해 나간다면 프로젝트에서 성공한 자신을 발견하리라 믿습니다.”

 

여기서 올바른 선택은 무엇일까?

 

선택을 통해 완벽한 결과가 나와야 올바른 선택인지, 결과는 좋지않지만 과정적인 면에서 효과가 나왔다면 그게 올바른 선택인건지는 확답할 수는 없겠지만 다양한 소프트웨어 환경에서 올바른 선택이 무엇인지에 대해 방향성을 제시해 주는 책이다.

 

이 책에서 애자일 소프트웨어 개발은 다음과 같이 정의한다.

 

"소프트웨어는 늘 변하는 환경이다."

 

소프트웨어 프로젝트는 팀 내 개발자들의 숙련도와 훈련, 경쟁력에 의존한다.

 

이 부분을 보더라도 이 책에서는 소프트웨어의 다양성과 무궁무진한 변수를 항상 고려하고 염두해야한다고 보고있다.

 

이 책에서 애자일 정신의 기원을 알 수 있다

 

이 책의 저자인 앤디 헌트 또한 Agile Developer 의설립자로 유타주 스노버드에 모인 17명중 1명이다.

 

애자일 정신의 기원은 다음과 같다.

 

20012월 경량 프로세스라고 막연히 불리며 떠오르던 경향에 대해 토론하기위하여 관심을 가진 사람들 17명이 유타주 스노버드에 모였다.

장황하고 , 부산물은 많고, 결과는 부실한 프로세스 때문에 프로젝트가 실패하는 것을 보아왔고, 방법론을 검토하는 좋은 수단이 있어야하는 필요성을 느꼈다.

 

17명은 애자일이라는 새로운 용어를 만들고 소프트웨어 개발에서 새롭게 집중해야할 접근 방법을 설명하기 위해서 애자일 선언을 공표하였다.

 

접근방법은 사람,(people), 협조(collaboration), 반응성(responsiveness), 동작하는 소프트웨어(working software)를 강조한다.

 

 

애자일 소프트웨어 개발 선언문

 

1.     프로세스와 도구보다는 개인과 상호작용

 

2.     포괄적인 문서화보다는 동작하는 소프트웨어

 

3.     계약 협상보다는 고객과의 협력

 

4.     계획 준수보다는 변화에 대응

 

왼쪽에 있는 것들에도 가치가 있지만, 오른쪽에 있는 것들에 더 가치를 둔다

 

더 많은정보는 http://agilemanifesto.org/

 

 

기원과 선언문에서도 볼 수 있듯이 애자일 접근 방법은 빠르게 반응하고 상호 협력하는 사람들과 논증 가능한 구체적인 목표를 결합하는 것이다.

 

애자일 실천방법은 어떻게 서술 했을까?

 

애자일 개발은 고도의 협력적인 환경에서, 지속적인 조정을 위해 피드백을 사용한다.”

 

개발작업을 공유하며 일하고, 소프트웨어 비용을 지불할 고객과 가까이 일하고, 그들에게 시스템의 최신버전을 가능하면 빨리 그리고 자주 보여준다.

 

이 과정에서 피드백을 얻고, 자동화를 사용해서 끊임없이 프로젝트를 빌드하고 테스트한다.

 

이것을 리팩터링(refactoring) 이라 하고, 개발하면서 계속해야하는 것이다.

 

라고 서술되어 있다.

 

결국엔 리팩터링(refactoring)은 끊임없는 커뮤니케이션이다.

 

이 책은 전체적으로 위에서 서술한 바와 같이 전체적인 애자일을 글로 느껴보고 싶은사람에게 추천을 하고싶고,

애자일 시작 -> 애자일 성장 -> 사용자들이 원하는 내용제공 -> 애자일 피드백 -> 애자일 코딩 -> 애자일 디버깅 -> 애자일 협력

으로 서술 되어 있다.

 

 

이 책을 읽다보면 마음에 와닿는 어구들이 많이 등장한다.

 

대표적으로 뽑자면

개인 감정을 드러내지 말고, 프로다운 자세를 유지하자.” 라는 어구가 굉장히 마음에 들었다.

 

나는 6개월동안 두 프로젝트를 진행하였다. 프로젝트를 진행하며 좋은사람들을 많이 만났지만 아닌 사람도 있었다.

그런 사람들을 보면 존경심보다는 피하고싶은 느낌밖에 들지 않았는데 그런사람들의 공통점이

개인감정을 드러내는데에 역력한 사람이였다.

그 사람들은 개인감정을 드러내기위해 틈을 놓치지 않았고, 사람을 몰아세우기를 좋아했다.

아마 업무에 대한 스트레스를 감정소비로 해소하는 사람 같았다.

 

마치 책 한권을 읽었는데 프로젝트의 시작과 끝을 경험해보는 느낌도 들었다.

 

취직하면 책은 안읽을 것 같았는데, 찾아보니 재밌는 내용이 많았다.

728x90
반응형
728x90
반응형

 

브룩스의 법칙(Brooks'law)는 "지체되는 소프트웨어 개발 프로젝트에 인력을 더

 

하는 것은 개발늦출 뿐이다" 라고 주장한 법칙이다.

 

그리고 브룩스는 "임산부가 아무리 많아도, 아이를 낳는 데에는 9개월이 걸린다" 라고 자신의 

 

주장을 표현하기도했다.

 

 

 

이 브룩스 법칙이 자주 인용되지만 

 

그의 저서 <맨먼스 미신>에 이 주장 위에 써있던 "극도로 단순화 해서 말하면" 이란 구문이 생

 

략되어 본뜻이 왜곡되어 전해지기도 한다.

 

-브룩스 법칙의 오해-

 

뛰어난 프로그래머와 일반적인 프로그래머 개인의 능력이 차이가 많이나기 때문에

 

매우 뛰어난 소수의 프로그래머를 이용하는것이 평범한 프로그래머를 고용하는 것 보다 생산성

 

이 높다는 것이다.

 

그러나 이것은 이론일 뿐이고 극소수 프로그래머만을 프로젝트에 투입하더라도 다양한 변수와 

 

환경적 조건이 적용 되어지기때문에 개발을 빨리 끝낼 수 있다고 말하는 것은 아니다.

 

 

-대표적인 해결책-

 

 

문제 전체를 소규모의 그룹이 맡을 수 있는 조각으로 나누고 , 상급 팀이 시스템 통합을 맡는 것

 

즉 , 트리 구조형식을 생각하면 될 것 같다.

 

하지만 이 또한 그룹 분배를 잘못하게된다면, 팀간의 의사소통비용이 더욱 늘어나게 되는 단점

 

 

 

테스트에서도 브룩스의 법칙이 적용될까?

 

100% 는 없다고 생각한다. case by case

 

예를들어 검증환경은 많지만 인원이 적은경우를 생각할 수 있다.

 

하나의 웹앱을 5개의 환경에서 검증한다고 할 때, 우수한 테스트 엔지니어 1명이 5개의 환경을 

 

모두 검증하는 시간과 5개의 환경을 파트를 나누어 평범한 테스트 엔지니어가 테스트를 하고 

 

우수한 테스트 엔지니어는 테스트 총괄담당하여 작업하는 시간을 비교한다면 그 무엇이 더 낫

 

다 를 판단할 수 가 없다.

 

하지만, 소프트웨어 테스트도 여러가지 skill 이필요하고, IT 산업의 다양해짐에 따라 

 

여러 분야를 테스트 해본 경력자가 확실히 프로젝트를 주도해 나아갈 수 있다.

 

실무를 하다보면 인원 추가가 필요한 시기가 있다. 인원 추가 시기에 어떤 인력을 투입하고 편

 

성하는 것은 프로젝트 매니저의 역량이라고 생각 되지만 인력 투입 후의 팀워크도 생각해 볼 필

 

요가 있다.

 

 

*피드백 환영합니다*

 

728x90
반응형
728x90
반응형

V O C (voice of customer)

 

 

 

 

 

voice of customer이라는 말 그대로 고객의 소리를 뜻 한다.

 

 

보통 서비스관련 회사에서 상담센터를 통하여 고객 불만 사항 등 다양한 이슈가 발생하는 경우

 

회사 내부에서 사용하는 고객관리시스템 용어이다.

 

 

voc에 대한 사전적 의미는 다음과 같다.

 

 

 

"관리 시스템 콜센터에 접수되는 고객불만사항을 접수부터 처리가 완료될 때까지 처리상황을 

실시간으로 관리하고 처리결과를 관서별로 지표화하여 관리·평가함으로써 고객의 체감서비스를 

 

향상시키는 고객관리시스템"

 

 

 

하지만 단순 콜센터에서만 voc 가 적용되는 것일까?

 

난 IT 분야에서도 다양하게 적용된다고 본다.

 

 

 

4차산업혁명 시대에 있어 빠르게 유입되는 기술과 정보로 고객들은 더 좋은 서비스를 요구한다.

 

 

기업은 고객들에게 단편적인 불만에만 대응하는 것이 아니라

 

 

회사 내부의 전반적인 고객응대 데이터와 기술력을 바탕으로 고객의 잠재적인 요구에 신속하게 대응하는 

 

 

Sense & Response 체제로 진화해야할 필요성이 생긴다.

 

 

이는 기업 서비스의 평판 관리 뿐 아니라 신제품 개발에도 스마트한 영향을 주기 때문이다.

 

 

(추가적으로 제 생각은 VOC 관점에서 수행하는 테스트는 기존 테스트 보다 고객사와 고객들에게 더욱 신뢰를 

줄 것이라 생각된다. Big Data분석을 통해 고객들이 공통적으로 요구하는 Data를 추출하여 테스트를 진행하게 된다면

기업은 고객만족도가 상당히 높은 상품을 시장에 내놓을 수 있을 것이다.)

 

 

개인적으로 테스트를 할 때, "개발자의 입장" , "고객의 입장" 에서 테스트를 하며 

 

개발자와 고객의 "gap" 을 줄여나가는 것이 중요하다고 생각된다.

 

 

 

 

 

*피드백 환영합니다*

728x90
반응형
728x90
반응형


몽고디비를 설치하기 위해서 


https://www.mongodb.com 


에 접속합니다.




Try MongoDB for Free 를 눌러서





컴퓨터 사양에 맞는 버전을 다운로드 합니다.





설치 파일을 실행시킵니다.


그리고 Next를 눌러줍니다.




라이센서에 관한 내용이니 읽어주고


Next 클릭합니다.



저같은 경우는 몽고디비를 기업목적으로 쓰려는게아니라


개인 공부를 위한 목적이므로 Complete 를 눌러주고 다운받았습니다.





Install 을 눌러줍니다.


기다리시면


설치가 완료 됩니다.


Finish를 눌러줍니다.


그리고


Path 시스템 변수에 몽고디비 설치 폴더 아래의 bin 을 추가합니다.


그리고 몽고디비는 저장될 위치를 사전에 정의 해주어야 합니다.


윈도우 사용자 계정 폴더 아래에 database/local 폴더를 생성합니다.(이름은 마음대로 하셔도 됩니다.)




이제 cmd 창에서%mongod --dbpath/Users/MOON/database/local

(즉, dbpath를 지정해주는 건데요 dbpath/Users/본인컴퓨터/사전생성한 폴더)

입니다.

그리고 입력하고나서 위와같은 프롬포트 창이 뜨면 정상적으로 연결된 것입니다.



그리고나서 CMD창을 하나 더 켜줍니다.


그리고 새로운 CMD 창에 mongo 를 입력해주시면


위와같이 연결된 것을 볼 수 있습니다.


이제 CMD창에서 여러 가지 명령어로 공부해보는 것은 다음 포스팅때 해보겠습니다.


728x90
반응형
728x90
반응형

 

 

 

강사님 구글정보 나의생각

 

docker 특강(hub.docker.com)

 

docker 란 무엇인가?

 

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼이다.

 

처음 강사님께 "여러분이 생각하시는 그 컨테이너가 맞습니다" 라고 했을때는 

 

긴가민가 했지만 google에서 검색을 해보니 그말이 진짜 맞았다.

 

말 그대로 배에 네모난 화물 수송용 박스이다. 각각의 컨테이너에는 서로 각기다른 다양한 화물을 적재할 수 있고

 

규격화 되어 있지만 컨테이너를 통해 손쉽게 옮길 수 있다.

 

서버에서 이야기하는 컨테이너 또한 다양한 프로그램, 실행환경을 컨테이너로 추상화 하고 동일한 인터페이스를 제공하여

 

프로그램의 배포 및 관리를 단순하게 하는 것이다.

 

그 어떤 프로그램이라도 컨테이너로 추상화 하여 어디든지 실행 할 수 있게 하는 것

 

그것이 도커(docker)라고 합니다.

 

구글은 모든 서비스들이 컨테이너로 동작하고 매주 20억 개 의 컨테이너를 구동한다고 합니다.

 

예전에 인터넷을 정보의 바다라고 했는데 그말이 대학생이 되어 소프트웨어학과에서 공부를하다보니 

 

이제서야 제대로 이해가 되네요.

 

Docker 는 컨테이너를 제공하는 소프트웨어 기술입니다.

 

윈도우 및 리눅스 에서 운영체제 수준의 가상화를 추상화 하고 자동화 하는 추가 계층을 제공합니다.

 

cgroups 및 커널 네임 스페이스와 같은 Linux 커널의 리소스 격리기능과 OverlayFs 및 기타와 같은 공용 가능 파일 시스템을

 

사용하여 독립적인 컨테이너를 단일 Linux 인스턴스 내에서 실행할 수 있게하여 가상컴퓨터를 시작하고 유지관리하는 오버헤드 입니다.

 

리눅스 커널의 네임 스페이스 지원은 주로 프로세스 트리, 네트워크 , 사용자 ID 및 마운트 된 파일 시스템을 포함하여 응용 프로그램의

 

운영 환경에 대한 뷰를 분리 하는 반면 커널의 cgroup 은 CPU , 메모리 , 블록 ,I/O , 네트워크 버전으로 되어 있습니다.

 

Docker는 Iibvirt, LXC(리눅스 컨테이너s) 및 systemd-nspawn을 통해 추상화 된 가상화 인터페이스를 사용하는 것 이외에도 Linux 커널이

 

제공하는 가상화 기능을 직접 사용하는 자체 방식으로 libcontainer 라이브러리를 포함합니다.

 

 

 

액션이 Docker 기본 이미지에 대해 수행되면 유니온 파일 시스템 레이어가 생성되고 문서화 되므로 각 레이어는 액션을 

 

다시 생성하는 방법을 완벽하게 설명한다.

 

이 전략을 사용하면 레이어 업데이트만 전파해야하므로 Docker의 경량이미지를 사용할 수 있다.

 

Docker는 다른 인터페이스를 사용하여 Linux 커널 가상화 기능에 액세스 할 수 있다.

 

Docker 는 높은 수준의 API 를 구현하여 프로세스를 독립적으로 실행하는 경량 컨테이너를 제공한다.

 

Docker 컨테이너는 Linux 커널 (주로 cgroup 및 네임 스페이스) 에서 제공하는 기능을 기반으로 구축되었으므로 가상 시스템과 달리

 

별동의 운영체제게 필요하거나 포함되지 않다.

 

그래서 libcontainer 라이브러리를 직접 사용하거나 libvirt, LXC (Linux Containers) 또는 systemd-nspawn을 통해 간접적으로 Linux 커널

 

의 가상화 기능에 액세스합니다.

 

그리고 Docker 컨테이너는 매우 가볍기 때문에 단일 서버 또는 가상 컴퓨터에서 여러 컨테이너를 동시에 실행할 수 있다.

 

Docker 를 사용하여 컨테이너를 만들고 관리하면 여러 응용 프로그램 , 작업자 작업 및 기타 프로세스가 단일 실제 컴퓨터 또는 여러 가상

 

컴퓨터에서 자동으로 실행될 수 있으므로 고도로 분산 된 시스템을 간단하게 만들 수 있다.

 

Docker는 작업 또는 작업 부하 큐 및 기타 분산 시스템의 생성 및 운영을 단순화 한다.

 

그리고 다음은 강의 내용입니다.

 

마이크로서비스 , 클라우드 ,등등

 

한 해가 바뀔때마다 트렌드가 바뀌고... IT가 변화한다.

 

4차 산업혁명(디지털 디스트럽션)

 

이 부분은 저번 공개SW대회에서도 들은 이야기 이다.

 

앞으로 오픈소스와 같이 더 쉽고 더 간편하게 그리고 더 많이 담을 수 있는 것들이

 

4차 산업혁명의 키워드 이자 나아갈 방향인 것 같다.

 

 

DevOps(디벨로퍼팀과 오퍼레이션팀이 같이있다) , Microservices , Containers , Cloud

 

요즘은 에자일 개발 방법론을 함

 

요즘 실무에 관해서는 에자일 방법론에 대해서 설명해 주셨다.

 

 

hub.docker.com 에 가면 도커에 있는 모든 이미지를 다운받을 수 있다.

 

 

why docker is hot - its simple , devs love it

 

왜 도커가 핫하고 지금 모든 관심이 있는지는 간단하다!

 

쉽고~ 개발자들이 좋아하니까!

 

Dev/Test of Legacy Apps

 

New App Dev

 

Code Agility, CI/CD pipeline, DevOps

 

Adoption of Open Source(새로운 기술을 접할때 굉장히 빠르게 접근함)

 

Microservices & Cloud Native Apps

 

 

 

IT 필드에서 도커가 핫한 기술임 (컨테이너 , 도커) 관심을 가지고 

공부를 해볼 것!!

 

마지막으로 IT계열로 취직을 하거나 관심이 있다면 Docker가 핫한 기술이니 관심을 가지라는 말씀으로 

 

끝을 내주셧다.

 

그래서 집에오자마자 노트북을 키고 Dokcer에대해 원리와 기본에대해서 잠시 공부를 해 보았다.

 

나아가 Docker로 어떤 프로그램을 설치할 지는 아직 정해지지 않았지만 Docker로 프로그램을 설치해서

 

써보도록 해보겠다.

 

 

728x90
반응형
728x90
반응형

 

 

젠킨스(Jenkins)는 소프트웨어 개발시 지속적 통합(continuous integration) 서비스를 제공하는 툴이다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다.

MIT라이선스를 따른다.

 

(MIT라이선스: 매사추세츠 공과대학교(MIT) 을 기원으로 하는 소프트웨어 라이선스 중 가장 대표적인 것이다.)

젠킨스는 원래 허드슨 프로젝트로 개발되었다. 허드슨의 개발은 2004년 여름에 썬마이크로시스템즈에서 시작되었다.

2005년 2월에 java.net 에 처음 출시 되었다.

 

(썬마이크로시스템즈(주) 는 컴퓨터,소프트웨어,정보 기술을 개발 및 제공하는 미국의 회사로 빌 조이(Bill Joy)에 의해 설립되었고. '네트워크가 곧 컴퓨터다'(The Network is the computer)라는 슬로건을 사용하였다. 썬이라고도 약칭한다.

썬은 대표적으로 솔라리스 운영체제,자바 플랫폼 등의 여러 소프트웨어들을 개발하였다.)

 

--썬마이크로즈는 2010년에 오라클에 공식 합병되었죠--

 

젠킨스는(Jenkins) CI툴이라고도 불리는데...

 

여기서 잠깐 CI를 설명하자면

 

소프트 웨어 공학에서 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이다.

작은 단위의 작업, 빈번한 적용, 지속적인 통합은 모든 개발을 완료한 뒤에 퀄리티 컨트롤을 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있다.

또한 ,연속적 빌드와 인터그레이션은 프로젝트의 성공 여부를 결정짓는 핵심요소이다.

CI(Continuous Integration)은 프로젝트에 투입되는 시간과 노력을 효율화 하는데 매우 중요한 사안이다.

CI의 특징으로는

 

1. 소스코드 일관성 유지

-소스 관리 시스템이 필요함

 

2. 자동 빌드

-커밋에 따른 자동 빌드

-시간 간격에 의한 빌드

 

3. 자동 테스팅

-빌드 과정에서의 테스팅(기능적 요소 및 비기능적 성능적 요소를 매번 검증)

 

4. 일일 체크아웃과 빌드

-소스의 무결성을 유지

 

 

 

========> 지속적 통합

 

이를 위해 나온것이 젠킨스라고 봐도 무방하다..

 

젠킨스와 같은 CI툴이 등장하기 이전에는 일정시간마다 빌드를 실행하는 방식이 일반적이였다.

 

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

 

젠킨스의 자동화된 빌드와 테스트 작업들은

 

-프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출

-자동화 테스트 수행

-결합 테스트 환경에 대한 배포작업

등등의 여러 가지의 플러그인을 온라인으로 간단히 인스톨 할 수 있는 제공을 기능하고 있다.

 

 

 또 추가 지식이 있으시다면 댓글로 +.+

 

 

 

 

 

728x90
반응형

+ Recent posts