블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'ALM/배포(Deployment)'에 해당되는 글 3

  1. 2013.10.15 Vagrant를 이용한 개발환경 자동화
  2. 2013.06.11 개발 환경(dev,stage,qa,production)
  3. 2009.04.30 JavaRebel (Not hotdeployment, no server restart)
 

Vagrant를 이용한 개발환경 자동화

ALM/배포(Deployment) | 2013.10.15 17:53 | Posted by 조대협

참고 : 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연동해보기.


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

개발 환경(dev,stage,qa,production)

ALM/배포(Deployment) | 2013.06.11 00:13 | Posted by 조대협

서버 개발을 가정하고, 먼저, 개발 및 운영에 사용할 서버를 어떻게 배치 해야할지를 살펴보자

일반적인 서버 개발환겨은 아래와 같이 local,dev,integration,qa,staging 그리고 production 환경을로 나뉘어 진다. 각자의 개발 과정에 따라, 각자의 역할과 목적이 다르고, 그에 따라서 시스템의 크기도 다르다.



꼭 모든 환경을 갖출 필요가 없으며, 프로젝트 환경에 따라서 각 환경을 합치거나 생략해도 된다.

그러면 각 환경에 대해서 살펴 보도록 하자.

환경

설명

local

로컬 개발 환경

먼저 개발을 하려면, 각자 개발자 PC에 개발 및 테스트 환경이 셋업 되어 있어야 한다. 각 개발자마다, 설치된 서버 환경을 local 환경이라고 한다. (. PC MySQL등의 DB Tomcat등의 제품을 설치하고, Eclipse와 같은 개발툴과, 컴파일러 등이 설치되어 있는 환경)

local 환경을 구축할시에 가장 주의해야 할점은 모든 개발자가 같은 개발 환경을 사용해야 한다는 것이다. 실제로 많이 일어나는 문제인데, 다른 version JVM를 사용하거나, 다른 버전의 Tomcat을 사용하거나 Lang (문자 local 설정)을 서로 다르게 해서, 정작 코드를 합칠때, local에서 잘 작동했던 코드가 작동하지 않는 경우가 많다.

개발 환경을 표준화 하는 방법은 여러 방법이 있지만, 전체 개발 환경 (JDK, Eclipse, 라이브러리) zip 파일 형태로 묶어서 사용하는 방법이 가장 일반적이다. 또는 뒤에서도 설명하겠지만, maven을 사용할 경우, 개발에 사용되는 JDK,라이브러리 버전등을 지정할 수 있기 때문에 개발환경 차이에서 오는 문제점 상당 부분을 해소할 수 있다.

dev
서버 개발 환경

개발 환경은 각 개별 개발자들이, 만든 코드를 합쳐서 서버 환경에서 테스트해볼 수 있는 환경이다. 소스코드를 형상관리 시스템에 commit하면, 코드는 이 dev 환경에 자동으로 배포되고, 이 환경에서 테스트가 된다.

기능 개발을 위주로 하기 때문에, 서버의 환경은 production 보다 훨씬 작다. 예를 들어 production이 클러스터링 환경으로 수개의 서버로 구성된다면, 개발 환경은 한 두 개의 서버로 기능 구현이 가능한 정도로 구축하는 것이 일반적이다.

Integration

통합 개발 환경

통합 개발 환경은, 여러개의 컴포넌트를 동시 개발하는 프로젝트가 있고, 각 컴포넌트가 다른컴포넌트에 대해서 dependecy를 가지고 있을때, 컴포넌트를 통합 및 테스트 하는 환경으로 사용한다.

예를 들어 단말과 서버를 같이 개발하는 환경의 경우 이 integration 환경에서 통합을 한다.

dev 환경과 마찬가지고, 최소한의 set으로 구성하되, dev 환경에서 release가 되면 주기적으로 deploy 한다.

qa

테스팅 환경

테스트 환경은 QA 엔지니어에 의해서 사용되는 환경으로, short release 주기에 따라서, 개발환경에서 QA 환경으로 배포 되고, 여기서 기능 및 비기능 (Load Test)등을 QA 엔지니어가 수행한다.

비 기능 테스트를 수행할 시에는, production과 거의 유사한 환경을 만들어 놓고, 테스트를 수행한다. (경우에 따라서는 비기능 테스트는 release전에, production 환경에서 직접 수행하는 경우도 있다. 이런 경우는 release cycle이 매우 긴 경우 주로 사용하는데, 기업의 내부 IT 시스템 만들어서 몇 년씩 사용 하는 경우와 같은 때 이런 방식을 이용한다

staging
스테이징 환경

운영 환경과 거의 동일한 환경을 만들어 놓고, 운영환경으로 이전하기 전에, 여러 가지 비 기능적인 부분 (Security, 성능, 장애등)을 검증하는 환경이다.

production
운영 환경

실제 서비스를 위한 운영 환경

 

대부분 개발환경은 별도로 운영하는 것이 일반적이고, 상황에 따라서 integration, qa, stating 환경은 요구 사항에 따라서 합치거나 별도 운영한다. 환경이 많아지면 조금 더 다양한 형태의 검증과 각 stakeholder (테스터, 개발자, 사용자 등)별로 테스트가 쉽지만 반대로, 각 환경을 유지 하는데, 필요한 서버들과, 운영 인력이 많이 소요되는 단점이 있다.

그래서 요즘과 같이 가상화 환경을 사용하는 경우에는  이미지를 만들어놨다가, 실제 테스트나 사용을 할 경우에만 가상 서버에 환경을 deploy해서 사용하고, 사용이 끝나면 다시 이미지를 스토리지에 저장해 놓는 전략을 많이 사용한다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
오늘 OKJSP의 테크 트렌드에서 본 좋은 제품 하나.. http://www.zeroturnaround.com/ Java Agent로 JVM을 Weaving하여, Zero downtime으로 redeployment를 가능하게 해준다. 얼마나 Production에서 제대로 동작할지는 모르겠지만, WLP.WLI는 몰라도, WLS에 전통적인 J2EE Application이나 Spring 기반의 Ap에서는 꽤나 쓸만할듯.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바