조대협의 블로그

참고 : http://ppiazi.tistory.com/m/post/view/id/230 1. vagrant 다운받아서 설치2. virtual box 다운 받아서 설치3. 우분트 precise32 버전을 설치 : vagrant box add "precise32" http://files.vagrantup.com/precise32.box 4. vagrant init precise32다음 vagrant up 으로 vm 실행 (virtual box에서 보면 실행된게 보인다.)5. putty ssh에서 localhost:2222로 접속6. default id/passwd는 vagrant/vagrant 다음에는 chef연동해보기.

Nexus 설치 및 Maven 연동조대협 Nexus는 maven에서 사용할 수 있는 가장 널리 사용되는 무료 repository 중의 하나이다. www.sonatype.com 에서 다운로드 받아서 설치할 수 있다. Local에 nexus를 설치하게 되면, 외부로 부터 dependency를 끌어 오는 수고를 덜고, local nexus를 proxy (cache)로 사용함으로써 빠르게 라이브러리들을 끌어 올 수 도 있고, 반대로 개발팀내에서 사용하는 공통 라이브러리들을 local nexus에 배포해서 팀간에 공유할 수 있다. 또한 사용자 계정 지정을 통해서 repository에 대한 접근 정책을 정의할 수 도 있다. Nexus는 repository의 용도와 목적에 따라서 몇 가지로 나눌 수 있는데, 대표적으..

nexus pro에 대한 고급 기능소개 조대협 (bwcho75@지메일) nexus는 maven repository로 매우 유명한 솔루션이다. 오픈 소스 버전은 maven을 사용하는 경우에는 거의 필수적으로 사용이 된다고 해도 과언이 아니다.nexus의 상용 버전인 nexus pro의 경우 CLM (Component Life-cycle Management) 개념을 도입하여, 접근제어나 컴포넌트에 대한 security 나 license risk등을 관리 통제할 수 있다.이 글에서는 nexus pro에 대한 몇 가지 고급 기능에 대해서 살펴보고, 이를 통해서 컴포넌트(라이브러리)의 관리가 단순한 중앙 집중형 공유만이 아닌 일종의 life cycle 개념이 있다는 것을 이해하도록 해보자 Nexus의 상용 버전인..

소스 코드 관리와 git조대협 (bwcho75@지메일)소프트웨어 개발에 있어서, 소스코드의 관리는 중요한 포인트 중의 하나이다. 다양한 버전과 변경 관리, 협업을 위해서는 소스코드를 저장 및 관리할 수 있는 시스템이 필요하고, 이를 VCS (Version Control System) 또는 SCM (Source Code Management) System이라고 한다. 소스코드 관리 시스템의 주요 기능은 다음과 같다.협업을 위한 코드 공유 - 여러 사람들이 협업을 할 경우, 코드를 각 개발자와, 팀간에 공유할 수 있어야 하며, 접근 제한 - 사용자의 권한 등급에 따라 접근을 제한해야 한다.다양한 버전(형상) 관리 - 소프트웨어 개발 버전 또는 릴리즈 (브랜치) 마다, 다른 코드를 저장할 수 있어야 한다. 예를..

참고 : http://nvie.com/posts/a-successful-git-branching-model/이 모델은 서비스 개발에 적절한 모델. (여러 버전을 동시에 릴리즈해서 유지 보수하는 솔루션 모델에는 맞지 않음) mastermaster는 외부 공개용으로, 항상 깔끔한 형상을 유지하며, 주요 milestone마다 tagging이 되어 있음. 기존의 release branch를 tagging으로 대체함release 여기서 release branch는 release 후에 없애 버리는 개념을 갖는데, release시 필요한 작업 공간으로 사용되며, minor fix 나 configuration 수정등을 위한 협업 장소로 사용됨.Fix된 내용들은 모두 release시 develop와 master로 mer..

1. git 기본 사용법$ echo "test materials" > index.html$ repository 생성$ git initInitialized empty Git repository in c:/dev/git/.git/$ echo "This is test materials" > init.html$ echo "This is test materials" > index.html$ git add index.htmlwarning: LF will be replaced by CRLF in index.html.The file will have its original line endings in your working directory.$ git status# On branch master## Initial co..

서버 개발을 가정하고, 먼저, 개발 및 운영에 사용할 서버를 어떻게 배치 해야할지를 살펴보자일반적인 서버 개발환겨은 아래와 같이 local,dev,integration,qa,staging 그리고 production 환경을로 나뉘어 진다. 각자의 개발 과정에 따라, 각자의 역할과 목적이 다르고, 그에 따라서 시스템의 크기도 다르다. 꼭 모든 환경을 갖출 필요가 없으며, 프로젝트 환경에 따라서 각 환경을 합치거나 생략해도 된다.그러면 각 환경에 대해서 살펴 보도록 하자. 환경 설명 local 로컬 개발 환경 먼저 개발을 하려면, 각자 개발자 PC에 개발 및 테스트 환경이 셋업 되어 있어야 한다. 각 개발자마다, 설치된 서버 환경을 local 환경이라고 한다. (예. 각 PC에 MySQL등의 DB와 Tomca..

http://nvie.com/posts/a-successful-git-branching-model/ 복잡하긴 하지만, 대략 흐름은 맞는듯.

Initializing a Repository in an Existing DirectoryIf you’re starting to track an existing project in Git, you need to go to the project’s directory and type$ git init This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet. (See Chapter 9 for more information about exactly w..

Plug in 을 통한 maven 빌드 확장 앞글에서 http://bcho.tistory.com/739 maven을 이용한 가장 기본적인 빌드 시나리오에 대해서 살펴보았다. maven은 plug in이라는 기능을 통해서, 여러 기능 들을 추가로 빌드 프로세스내에 추가할 수 있는데, 여기서는 빌드에서 확장하여, 배포 환경 별로 패키징 하는 시나리오를 추가해보기로 한다. 다음과 같은 시나리오를 생각해보자, 빌드에 의해서 생성된 웹 애플리케이션은 내 local PC에서도 돌아가야 하며, 다른 개발자와 협업하는 서버의 개발환경에서도 돌아야 하고, 개발 주기마다 주기적으로 QA환경에서 테스트를 받은 후, staging 환경을 거쳐서 최종적으로 production 환경에 배포 되어야 한다고 가정하자. Java Ve..