[Agile] 협업 개발 프로세스
기본적으로 위와 같은 구성으로 협업에 따른 개발이 이루어지는 것 같다. 위에서 본인이 경험한 업무 프로세스에 대해서만 간단히 요약하겠다.
1. JIRA를 활용한 협업
현재 근무하는 곳에서는 Jira를 사용하고 있었다.
주로 프론트 오피스에서 작업 요구사항이 생기면 이것이 백 오피스쪽으로 넘기게 된다. 이를 Jira라는 협업도구를 통해 형식에 맞추어 정리하여 요구한다. 현 근무하는 곳에서는 직원이 Jira 요청서를 본인 부서 매니저에게 승인 요구를 올린다. 이에 대해 매니저의 OK가 떨어지면 요청서가 순차별로 이루어진다.
일감 작성은 회사마다 다르고 내규 정보이기에 생략하겠다.
자세한 건 링크를 참조하면 좋을 것 같다.
2. 소스 코드 수정 작업
매니저의 컨펌이 확인되면 해당 작업에 대해 수정을 시작한다.
해당 요청사항에 따라 수정을 시작한다. 해당 소스 수정이 어떤 것을 요구하는지에 따라 사용하는 IDE가 다를 수도 있고 다른 Tool을 연동해서 사용하는 경우가 있다.
아직 본인은 간단한 기간계 소스 수정 밖에 안하여 다른 툴을 많이 사용해보지는 않았으나, SQL 활용을 필요로 하는 경우 DataGrip이나 SSMS(microsoft sql server management studio)등의 SQL tool 또한 활용할 수 있을 것이다.
- SSMS는 위처럼 생겼다. RDBMS 중 ms-sql 사용 시 주로 사용한다.
기본적으로 간단한 백 단만 수정이 필요할 경우 eclipse로 간단한 수정만 한다. 이 곳의 프론트 단 중 레거시 시스템은 xrw 확장자 파일을 TrustForm을 이용해서 수정하기는 하는데.. 잘 만지지는 않는다. 언어도 VisualBasic과 JS 여러가지 섞여 있는 것 같아서 쉽지 않다.
차후 스프링부트로 API 작업도 한다면 Swagger와 같은 Tool 또한 사용할 수 있을 것 같다. 스웨거는 개발자가 REST 웹 서비스를 설계, 빌드, 문서화, 소비하는 일을 도와주는 대형 도구 생태계의 지원을 받는 오픈 소스 소프트웨어 프레임워크라는데 차후 사용하면 정리해 보겠다.
자세한 건 링크 참조
배치 서버를 수정하는 경우에는 Visual Studio와 SSIS를 응용하여 수정하는 경우도 있었다.
- SSIS, 위처럼 흐름에 따라 작업을 진행하는데 배치 서버 작업 시 주로 사용했다.
위와 같은 작업들을 로컬에서 마무리하게 되면 이렇게 수정한 소스들을 commit하게 되는데 이 때 SVN, GIT과 같은 형상관리 Tool을 사용한다.
3. 형상 관리 Tool
소스 수정이 완료되면 repoistory에 해당 소스를 commit한다.
서버 개발 환경(dev), 운영 환경 (production)으로 크게 나뉘어 작업이 이루어지는데 당연하게도 dev에 먼저 push를 하게 되고 해당 dev에서 여러 테스트를 거친 뒤 이상이 없으면 아래 순차적으로 다양한 환경으로 옮겨져 테스트를 해본 이후 마지막으로 production으로 이송하는 시스템이다.
이러한 환경들은 아래처럼 여러가지가 있다.
DEV
각 개별 개발자들이 만든 코드를 합쳐서 서버 환경에서 테스트해볼 수 있는 환경
소스코드를 형상관리 시스템에 commit하면 이 코드는 dev 환경에 자동으로 배포되고 이 환경에서 테스트가 된다
기능 개발을 위주로 하기 때문에 서버 환경은 production보다 훨씬 작다.
production이 클러스터링 환경으로 수개의 서버로 구성된다면 개발 환경은 한 두개의 서버로 기능 구현이 가능한 정도로 구축하는 것이 일반적이다.
Integration
통합개발환경
여러 개의 컴포넌트를 동시 개발하는 프로젝트가 있고 각 컴포넌트가 다른 컴포넌트에 대해서 depency를 가지고있을 때 컴포넌트를 통합 및 테스트 하는 환경
dev 환경과 마찬가지고 최소한 set으로 구성하되, dev 환경에서 릴리즈가 되면 주기적으로 deploy한다
ex) 단말과 서버를 같이 개발하는 환경의 경우 이 환경에서 통합 진행
QA testing
QA 엔지니어에 의해서 사용되는 환경
short release 주기에 따라서 개발 환경에서 QA 환경으로 배고되고 여기서 기능 및 비기능(Load Test)등을 QA 엔지니어가 수행
비기능 테스트를 수애할 시에는 production과 거의 유사한 환경을 만들어 놓고 테스트 수행.
Staging
prod환경과 거의 동일한 환경을 만들어 놓은 환경
prod환경으로 이전하기 전에 여러가지 비 기능적인 부분(Security, 성능, 장애 등)을 검증하는 환경
Production
실제 서비스를 위한 운영 환경
local 서버에서 각자 코드를 만들고 깃허브 등을 이용해 개발자들끼리 dev 서버에서 코드를 합쳐 qa 등 테스트를 충분히 해보고 stg에 올려 실제 기능을 점검, 검증한 뒤 prod로 운영
기본적으로 수정 소스를 commit하기 이전에 해당 소스가 포함된 패키지를 Repository와 동기화를 시키고 미리 update를 진행하고 충돌이 있는 소스를 확인하여 merge 후 commit 시킨다.
이후 deploy 작업은 후술할 Jenkins를 이용한다.
4. Jenkins (CI 툴)
젠킨스는 소프트웨어 개발 시 지속적 통합 서비스(CI)를 제공하는 툴이다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다.
사실 이 부분부터는 아직 많은 작업을 하지 않았기 때문에 잘 모른다.
docker 같은 container 툴은 이 곳에서 사용하지 않아서
사실 소스 commit 이후 build 및 deploy를 위해 주로 사용한다.
어떠한 소스를 수정했는지에 따라 다르겠지만 사용하는 WAS에 수정 및 적용을 위해서는 Jenkins를 통해 해당 파일을 Deploy 시켜주고 이후 Reboot 시키는 작업을 진행한다. WAS는 익히 아는 Tomcat과 Jeus 등의 동적 파일을 실행하는 Web Application Server 맞다. 정적 컨텐츠를 배포하는 경우는 훨씬 더 간단하다. 웹 서버로는 Apache를 사용한다.
- Jenkins 툴, Build History에서 배포 후 다양한 개발자들의 빌드한 이력을 볼 수 있다.
이 과정에서 알람 기능으로 slack 등으로 개발자 등에게 배포 완료 알림이 가는데 뭐 outlook 등의 메일을 활용하는 경우도 있고 다양하다.
5. 테스트 및 실환경 적용
테스트는 Java 소스면 JUnit, RestAPI 등의 Web 기반 API 프로그램이면 PostMan 등 다양한 걸 사용하는 것 같은데 QA를 해본 것은 아니라 자세히 모른다..
테스트 이후 이상 없으면 해당 관리자에게 요청해서 실환경에 적용하게 된다. 이 과정에서 Jira 요청서를 수정하는 등의 작업 등도 거치게 된다. 이 챕터는 관련 정보에 대해 더 알게 되면 후술하도록 하겠다.
