메뉴 건너뛰기

이 문서는 Release Automation의 분류에 대해 설명합니다.


본 문서는 다음링크의 글에 영향을 받아 2014년 5월에 작성한 문서의 일부입니다.

https://devops.com/approaches-to-application-release-automation/


지금은 익숙한 개념인 Hudson/Jenkins와 같은 어플리케이션 빌드배포 자동화 툴의 시간흐름에 따라 나타난 유형을 분류해본다면 다음과 같이 나눠볼 수 있습니다.


<그림 1. Release Automation의 유형과 특징>

Release Automation 특징.PNG


패키지기반: <서버패치, Windows 패치>
패키지 기반 배포는 원래는 server 자동화로부터 나온 개념입니다.
서버자동화의 개념이 명확하므로 큰 성공을 가져오자 그것을 SW배포에 활용한 경우에 이런 유형에 해당합니다.
그렇다면 서버자동화란 무엇일까요?

서버가 조직내에서 어떤 역할을 하는지, 서버가 제공하는 서비스는 무엇인지 식별하고 같은 방식으로 관리되는지, 누가 서버들간의 표준을 지정하는가 등을 고려할 수 있는 정보를 수집/판단하는 과정입니다.
물리/가상서버를 불문하고 하나의 관리콘솔에서 대상 서버에 지정된 설정 값, 서버타입, 파일시스템, 하드웨어정보, 사용자 그룹 등의 값을 관리할 수 있는 툴이 이 작업에 활용됩니다.


선언기반:
원하는 서버상태를 Domain Specific language로 기술하며 부가적으로 몇몇 스크립트 사용가능합니다. 이때 원하는 서버상태란, 각각의 config에 해당하는 즉, 레지스트리 키 값 dll config파일 등이 해당합니다. DSL은 일종의 코드로 해당 설정값을 지정하기 위한 형태이며  DSL을 사용하므로 개발자가 아닌 경우에는 특히 접근성이 좋지 않다는 단점이 있습니다.
패키지 기반과 마찬가지로 서버가 독립적으로 설정되는 경우를 가정하고 있다는 한계가 있고 자동롤백이 쉽다는 장점이 있습니다.

여기서 서버가 독립적으로 설정된다는 것은 다른 서버와의 동기화, 의존성이 없거나 고려하지 않음을 말합니다.


명령기반:
명령기반툴은 중간형태의 코드가 생성되기도 하지만, 기본적으로 java와 C++ perl과 같은 언어와 유사한 구조를 사용합니다. 대표적인 툴이 Chef라는 툴인데, 이 툴은 Ruby를 기반으로 합니다. 이 형태의 툴 역시 기본적으로 단일 고립형 서버에 대한 변경을 염두에 두고 있으나, 엄밀히 말하자면 같은 타입의 서버에는 같은 변경이 일어난다 라는 가정을 하고 설계되어 있습니다.


자체개발:
자체개발형 자동화툴은 사용하는 당사자가 가장 잘 사용할 수 있는 언어로 구성하여 빌드에서 배포까지 깔끔하게 수행가능하다는 점에 있어서 훌륭하지만, 기술적으로 여러 서버간의 동기화, 병렬수행, 리포팅과 감시기능, 제어 권한에 대한 어려움이 있습니다. 기본적으로 개발팀에서 주체적으로 만든 빌드툴이기 때문에 bottom up방식이며, 해당 팀의 SW를 배포하기 위한 코딩으로 이루어집니다. 팀 단위 또는 전사 규모의 커스텀 툴을 개발한 경우로 볼 수 있습니다.


프로세스기반:
프로세스 기반 툴은 자체개발 툴 또는 기존의 수동배포 프로세스를 그대로 지키면서도 전사적인 프로세스 정립에 도움을 주는 빌드자동화툴로, 공통/일반적인 라이브러리를 생성 관리할 수 있다는 특징이 있습니다.

주로 시각화 모델로 프로세스를 구현할 수 있으며 업무별로 연관있는 서버군과 어플리케이션을 논리적으로 연결합니다.


문서가 작성된 시점에는 새로이 등장한 유형이었던 이기종 클라우드를 위한 어플리케이션 중심 자동화툴도 근래에 활발하게 소개되고 있습니다. UrbanCode Deploy with patterns라든가, Cisco CloudCenter / ACI가 여기에 해당합니다.

On premise에서 퍼블릭 클라우드로 넘어가는 과정에서 일부 하이브리드 클라우드 상태가 되는 것은 어쩌면 자연스러운 일이고, 퍼블릭 클라우드로 전환하는 과정에서 기업은 벤더에 종속되는 현상인 lock-in을 우려하게 되는 것 또한 당연합니다. 이러한 문제를 해결하기 위한 어플리케이션 중심 접근방법 역시 IT환경 자동화를 위한 Continuous Delivery라고 말할 수 있을 것 같습니다.


<그림 2. Release Automation 유형과 툴>

Release Automation 툴.PNG


위 그림은 앞서 설명한 Release Automation의 유형과 이에 해당하는 툴을 보여줍니다.

글의 서두에 시간의 흐름에 따른 유형이라고 표현하고 자동화 툴의 역사라고 표현하지는 않았는데, 그 이유는 새로운 개념의 유형이 전 단계의 니즈를 완전히 만족하거나 대체하는 것이 아니기 때문입니다.


즉, 각 유형은 그들의 영역에서 발생하는 새로운 니즈를 만족하기 위해 현재까지도 꾸준히 발전하고 있고 앞서 설명한 태생적 특징을 극복하기 위한 다양한 개념을 활발하게 소개하고 있습니다. 예를 들면, Chef나 Puppet에서도 Application 배포에서의 Orchestration 니즈를 만족하기위한 기능을 볼 수 있습니다.

Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

?
  • profile
    Tom 2017.12.14 15:58
    좋은 정보 감사합니다. :)

 


  1. No Image

    Microservices, Monoliths and Self-Contained Systems (1) Monoliths

    Monolith (1. 단일 암체;(특히 고대의)거대한 돌기둥 2. (변화가 느리고 개개인에게 무관심한)거대한 단일 조직 모노리스(Monolith)에 대해 알아봅시다. 모노리스는 가장 기본적인 소프트웨어 아키텍처입니다. 만일 여러분이 특별한 계획 없이 코딩을 시...
    Date2017.12.13 ByNeO Reply0 Views319
    Read More
  2. Microservices, Monoliths and Self-Contained Systems (0) 서문과 인포그래픽

    이 문서는 다음 링크의 글을 번역했습니다. https://blog.appdynamics.com/engineering/microservices-monoliths-and-self-contained-systems-time-to-break-it-down/ 문서가 길어서 분할하여 게시합니다. (0) 서문과 인포그래픽 (1) Monoliths (2) M...
    Date2017.12.13 ByNeO Reply1 Views364
    Read More
  3. No Image

    개발자관점에서 APM의 중요성

    이 문서는 다음 링크의 글을 번역했습니다. https://blog.appdynamics.com/product/the-importance-of-apm-for-developers/ The Importance of APM for Developers   소프트웨어 개발자를 중세시대의 장인과 비교해봅시다. 과거에는 나무를 가구로 만드는 ...
    Date2017.12.04 ByNeO Reply2 Views814
    Read More
  4. Release Automation의 분류

    이 문서는 Release Automation의 분류에 대해 설명합니다. 본 문서는 다음링크의 글에 영향을 받아 2014년 5월에 작성한 문서의 일부입니다. https://devops.com/approaches-to-application-release-automation/ 지금은 익숙한 개념인 Hudson/Jenki...
    Date2017.12.01 ByNeO Reply1 Views606
    Read More
Board Pagination Prev 1 2 3 Next
/ 3