ICE4 GIT Flow for DevOps

Owned by william (Unlicensed)
Apr 15, 2021
5 min read

 

 

Purpose(en)

This document is to define GIT Flow for ICE4 develop, Also involved in Jira issue id

 

GIT Flow(en)

Define

It has been made by Vicent Dressen, in 2010. Git work process is like below using the Git branch.

  • master: Always able to deploy on the Production server

  • develop: This branch is a function to develop and deploy version control. Not only share between developers but also developer pull and push to develop branch.

  • release: For deploy version release.

  • feature: function to develop

  • hotfix: for emergency or bug fix branch after deploy

Master and Develop brach is the main brach to use commonly. Release, Feature, Hotfix is sub-branch to use temporarily. Also Developer able to use multiplex branch model such as bugfix, an improvement on sub-branch.

Process

The general process like below

  1. develop branch folk from a master branch only one time when we create a new project

  2. folk into feature branch when developer develops featured function

  3. folk release branch from develop branch to deploy

  4. use a release branch to test. when we fail, bug fixes directly into a release branch.

  5. release branch merge into master and develop branch after test complete

Even though this git-flow is able to clearly classify between developing and release, It is not cover to the pursuit of continuous integration DevOps environment. As a result, We have to define Git flow more suitable for DevOps

 

ICE4 - GIT Flow(en)

Define

To define Git flow as a CI/CD DevOps, we can apply the Develop-Staging-Production branch which is generally used in a project.

  • develop: feel free to use and whole process test in develop step

  • staging: To the whole test before deploy

  • production: When test finish in staging step, merge and deploy into production

we define develop, staging, production to generally use as the main branch while in the processing to develop the function. define like below:

 

 

Process

  1. Create new branch using Jira issued ID from develop branch

    $ git branch story/ICE4-120 $ git branch improvement/ICE4-121

  2. To process develop and test function using created brach according to Jira issue id

    1. Developed source commit

    2. Write test scenarios

    3. Write test script using postman and selenium

    4. Run test and bug fix

  3. When complete develop in sub-branch, merge into develop branch

    $ git checkout develop $ git merge --squash story/ICE4-120 $ git commit -m 'Merged in story/ICE4-120’ $ git push origin develop

    At this time, using --squash to integrate from a lot of commit as a 1 commit

  4. run the simple test for merged source in develop branch

  5. To apply the completed issue, rebase to the staging branch. And then the final test. To choose a merged issue on staging branch, use interactive rebase

    $ git checkout staging $ git merge develop $ git rebase -i origin/staging

    to check commit list, use rebase -i

    pick commit source to delete and save except merging in production after all test and review completed source

    it is able to merge which is developer’s wanted(story/ICE4-120) to commit on staging only
    When merge complete on local, push to complete all process. Also when face problem while in the merge, use rebase --abort to cancel. and delete branch after the merge

  6. Run total test on staging branch

  7. when total test finish, merge into production. If you change some source code, please edit develop branch as well

 

 

Purpose(kr)

ICE4 개발에서 사용하기 위한 GIT Flow를 JIRA와 연계하여 정의합니다.

 

GIT Flow(kr)

정의

2010년 Vicent Dressen이 만들었으며 다음과 같은 브랜치를 이용하여 작업을 진행합니다

  • master: 언제나 상용서버에 배포가 가능할 수 있는 브랜치

  • develop: 기능 개발 및 배포 버전을 준비하고 개발자들 간 공유 pull/push 해야 하는 브랜치

  • release: 배포 버전 출시를 위한 브랜치

  • feature: 기능을 개발하는 브랜치

  • hotfix: 배포된 이후 긴급 또는 버그를 수정하는 브랜치

고정적으로 이용하는 master와 develop를 메인 브랜치라고 하며 release, feature, hofix와 같이 일정 기간동안만 사용하는 브랜치를 보조 브랜치라고 합니다. 보조 브랜치에는 bugfix, improvement 와 같은 다양한 브랜치 모델을 추가하여 사용하기도 합니다.

Process

일반적인 작업 절차는 다음과 같습니다.

  1. master 에서 develop 브랜치 분기 - 최초 한번

  2. 특정 기능 구현이 필요하면 feature* 브랜치 분기

  3. 배포를 위해서 develop로부터 release 브랜치 분기

  4. release 브랜치를 이용하여 테스트를 진행하고 테스트에서 발생하는 버그는 release 브랜치에 직접 반영

  5. 테스트 완료후 release 브랜치를 master와 de

이러한 GIT Flow는 개발과 릴리즈를 명확히 구분하여 관리할 수 있는 장점이 있지만, 지속적은 통합(CI)을 지향하는 DevOps에는 적합하지는 않습니다. 따라서, 우리는 DevOps에 적합한 GIT Flow를 정의해야 합니다

 

ICE-GIT Flow(kr)

Define

DevOps의 CI/CD를 지원하는 GIT Flow를 만들기위해 프로젝트 진행시에 통상적으로 사용하는 Develop, Staging, Production 개념을 도입하여 브랜치를 분리하는 방안을 적용하였습니다

  • develop: 개발단계에서 부담없이 통합 테스트를 진행할 수 있는 브랜치

  • staging: 배포 전에 통합 테스트를 실행할 수 있는 브랜치

  • production: staging에서 테스트가 완료되면, production으로 merge하여 바로 배포하는 브랜치

따라서, 고정적으로 사용하는 메인 브랜치를 develop, staging, production으로 나누고 개발 진행할때 develop로부터 브랜치를 생성하는 방법으로 다음과 같이 플로우를 정의합니다

 

 

Process

  1. develop 브랜치로부터 Jira의 이슈 아이디를 이용하여 새로운 브랜치를 생성합니다

  2. 생성된 브랜치를 이용하여 개발 및 테스트를 진행합니다

    1. 개발된 내용 커밋

    2. 테스트 시나리오 작성

    3. 테스트 스크립트 작성 (Postman, Selenium) 및 커밋

    4. 테스트 실행 및 버그 픽스

  3. 브랜치에서 개발이 완료되면 develop로 merge 합니다

    이때, --squash 옵션을 이용하여 브랜치의 여러 커밋을 하나의 커밋으로 합쳐 줍니다

  4. 머지된 develop 브랜치를 이용하여 간단한 테스트를 수행합니다

  5. 완료된 이슈를 반영하기 위하여 staging으로 옮겨서 최종 테스트를 진행하여야 합니다. 이때, 머지된 이슈를 선별하여 staging에 병합할 수 있도록 interactive rebase를 이용합니다

    이렇게 rebase -i 옵션을 이용하면 다음과 같이 커밋 목록이 나타납니다

    이중에서 모든 테스트와 리뷰가 완료되어 production에 반영할 커밋 내용(story/ICE4-120)을 제외한 다른 커밋은 삭제하여 저장합니다

    이렇게 하면 선택한 story/ICE4-120 만 staging에 merge 되는 것을 확인할 수 있습니다
    로컬에서 머지가 완료되면 최종적으로 push를 하여 작업을 완료합니다. 그전에 문제가 발생하면 rebase --abort를 이용하여 취소합니다. 그리고, 생성하였던 브랜치는 삭제합니다

  6. staging 브랜치를 이용하여 통합 테스트를 진행합니다

  7. 통합 테스트가 완료되면, production 브랜치로 머지합니다. 이때 변경사항이 있다면 develop 브랜치에도 merge를 실행합니다