개발환경
개발 단계
컴파일 → 빌드 → 배포
- 컴파일 : 사용자가 작성한 코드를 컴퓨터가 이해할 수 있는 언어로 번역하는 일
- 빌드 : 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일
- 배포 : 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일
❗ 혹은 컴파일을 포함해 war, jar 등의 실행 가능한 파일을 뽑아내기까지의 과정을 빌드한다고도 함.
🌱 출처 : https://itholic.github.io/qa-compile-build-deploy/
서버 개발 단계
개발자 개인PC -> 빌드서버 -> 개발서버 -> QA서버 -> 운영(라이브) 서버
🌱 출처 : https://www.sten.or.kr/bbs/board.php?bo_table=free&wr_id=24591
Local(로컬 개발 환경)
먼저 개발을 하려면, 각자 개발자 PC에 개발 및 테스트 환경이 셋업 되어 있어야 한다.
각 개발자마다, 설치된 서버 환경을 local 환경이라고 한다.
📌 예) 각 PC에 MySQL등의 DB와 Tomcat등의 제품을 설치하고, Eclipse와 같은 개발툴과, 컴파일러 등이 설치되어 있는 환경
❗ 이 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 (스테이징 환경)
운영 환경(Production)과 거의 동일한 환경을 만들어 놓고, 운영환경으로 이전하기 전에, 여러 가지 비 기능적인 부분 (Security, 성능, 장애등)을 검증하는 환경이다.
Production(운영 환경, 라이브 서버)
실제 서비스를 위한 운영 환경
❗ 서버 이중화가 되어있다는 의미 = 라이브 서버가 두개다
ETC
대부분 개발환경은 별도로 운영하는 것이 일반적이고, 상황에 따라서 integration, qa, stating 환경은 요구 사항에 따라서 합치거나 별도 운영한다.
환경이 많아지면 조금 더 다양한 형태의 검증과 각 stakeholder (테스터, 개발자, 사용자 등)별로 테스트가 쉽지만 반대로, 각 환경을 유지 하는데, 필요한 서버들과, 운영 인력이 많이 소요되는 단점이 있다.
💡 해결 방안 💡
그래서 요즘과 같이 가상화 환경을 사용하는 경우에는 이미지를 만들어놨다가, 실제 테스트나 사용을 할 경우에만 가상 서버에 환경을 deploy해서 사용하고, 사용이 끝나면 다시 이미지를 스토리지에 저장해 놓는 전략을 많이 사용한다.
🌱 출처 : https://bcho.tistory.com/759
배포
Release
같은 제품을 새롭게 만드는 것
📌 예시
- ip address를 release한다는 말 = 새로운 아이피 번호를 부여받는 말
- 제품에선 새로운 버전을 release 한다고 할때 사용
🔍 특징
- 디버그에 대한 정보가 없으며, 코드를 최적화하여 실행파일 크기를 최대한 줄여줌
- 초기화를 하지 않으며, 같은 문자열 상수라도 서로 다른 공간에 할당됨
- 속도와 크기, 메모리 사용면에서 디버그 보단 좋음(메모리 점유율이 낮음)
- 디버깅 정보 없이 순수한 코드 자체의 기능만 담긴 파일
- 더 이상 문제점이 없을 때, 빌드해주는 것이 좋음
Debug
- 실행파일에 디버깅 정보를 삽입하여 언제든지 디버깅을 할 수 있도록 하며 debug서브 폴더에 실행파일을 만들어줌.
- 디버깅 정보가 들어가 있기 때문에 실행파일 상태를 확인할 수 있습니다.
- 디버그에 필요한 정보들을 실행시 계속 체크함으로써 속도가 느립니다.
Debug와 Release의 차이점
- 디버깅 정보를 실행코드 안에 넣는 지 유무의 차이
👉 Debug - 넣음 /Release - 넣지 않음
💡 차이점 설명
- 디버거 모드로 컴파일하게 되면 실행상태에서 추적할 수 있는 정보가 실행파일 안에 들어가게되므로 용량이 커짐
- 릴리즈 모드의 경우 디버깅 정보없이 순수한 소스코드 자체의 기능만 컴파일되어 실행파일로 만들짐
🔍 Debug와 Release 빌드에서 서로 실행 결과가 다른 경우
특히 디버그 빌드에서는 괜찮은데 릴리즈 빌드에서만 오류가 발생하여 프로그램이 죽는 경우가 있는데, 이런 경우는 대부분 메모리가 깨진 경우에 발생합니다.
👉 두 모드에서 동적으로 메모리를 할당하면 힙 영역에서 요청한 크기만큼 할당받게 되는데 그 초기값이 다릅니다.
Deploy
프로그램 등을 서버와 같은 기기에 설치하여 서비스 등을 (작동 가능하도록) 제공하는 의미
Distribute
제품을 사용자들이 사용할 수 있도록 서비스 등을 제공하는 의미
ex) 삼성App2가 새롭게 release 되었고, 이를 서버에 deploy하여 사용자들이 사용할 수 있도록 distribute하였다.
🌱 출처
https://m.blog.naver.com/jysaa5/221767221440
https://ukcasso.tistory.com/73
