작은 규모의 서비스는 운영 WAS를 직접 건들여 가며 작업을 할 수도 있다. 또는 로컬에서 테스트 하다가 새벽에 살짝 업데이트 할 수도 있다. 현재 접속된 세션만 소실될 뿐 큰 리스크는 없기 때문이다. 하지만 실시간 이용자가 어느 정도 많아지고 규모가 커지면 더 이상 그렇게 무모한 운영은 불가능하다. 이럴 땐 주로 개발계, 운영계를 구분하여 개발계에서 개발/테스트 후 형상관리를 통해 운영계에 배포하는 이중 작업이 필요하다.
이를 도와주는 관련 솔루션도 많지만 우선은 정말 간단히 구별할 수 있는 이론적인 방법을 살펴보자.
우선 작업 폴더를 ctrl+c, ctrl+v하여 복사한다. 특정한 위치에 sysdef.php(아무 이름이나 가능하다. php가 아니라면 sysdef.js, sysdef.java등)라는 파일을 만든다. 해당 파일에 현재 서버가 개발계인지, 운영계인지 구분한다. $debug_mode = true/false로 구분해도 되고 $was = operating/developing 으로 구분해도 된다. 자유롭게 구분한다. (변수보다는 가급적 상수를 사용하는게 좋다.) 그리고 별도로 구분해야 될 상수가 있다면 정의 한다. 절대경로라던가, 이미지서버, 포트 등 개발과 운영이 다르게 적용되는 부분은 다 명시해 준다.
그리고 나머지 소스에선 해당 파일을 include하여 개발계인지 운영계인지를 분기하여 코딩한다. sysdef.php의 내용이 개발계를 기준으로 정의되어 있다면 개발계에서 돌아가고 운영계를 기준으로 정의되어 있다면 운영계에서 돌아가도록.
작업 폴더를 2개로 만들었으므로 웹서버 또한 2개로 만들어야 한다. 계정을 하나 더 만들거나 폴더를 분리하고 도메인을 구분한다. 서브 도메인을 사용하면 편하다. 그리고 각각의 폴더를 업로드 하고 한쪽엔 개발계를 기준으로 작성된 sysdef를, 한쪽엔 운영계를 기준으로 작성된 sysdef를 올린다.
그리고 sysdef는 로컬에선 삭제 해 버린다. 형상관리 대상이 아니다. 이 파일은 서버에만 있고 레파지토리엔 없다. sysdef 외의 다른 소스만 수정하고 개발계에 배포하여 테스트 한다. 테스트가 잘 된다면 같은 소스를 그대로 운영계 서버에 배포한다. 각 서버에 올라가 있는 sysdef가 다르기 때문에 같은 소스를 올리더라도 각 서버에 맞게 동작을 하게 된다.
개발의 규모가 좀 크다면 개발/테스트/운영 3단계로 구분해도 좋다. 개발계에선 빈번하게 소스가 변경이 되고, 어느 정도 완성이 되었다면 테스트계로 배포하여 테스트계에서 QA를 거친다. 검증이 완료되면 운영계로 올려 업데이트 한다.
'IT 실무' 카테고리의 다른 글
검색엔진의 기능을 하지 못하는 네이버. 오만한 대응 (1) | 2017.10.26 |
---|---|
클라우드란 무엇인가!? 클라우드 컴퓨팅의 기본적 개념 (0) | 2016.11.21 |
현재 기준으로 등록 가능한 3글자 kr도메인 (0) | 2016.08.19 |
[Unitalk.xyz] nodejs를 이용한 랜덤채팅 프로젝트 (1) | 2016.01.04 |
주간, 월간, 실시간 랭킹 구현하기 (0) | 2015.07.19 |
댓글