쏘니헨리

데이터베이스 튜닝에 대해 언제,누가,어떻게,무엇을 왜 하는지 살펴보고자 한다 ~ !! 

데이터베이스 튜닝이란 ??

데이터베이스의 성능 향상을 위하여 운영체제나 DB자체의 구조를 이해하고 필요한 요소를 변경하는 작업을 말한다.

데이터베이스를 단순히 데이터의 저장과 인출 등의 목적으로만 활용하는 것이 아니라 실제 서비스 운영에 있어 성능은 매우 중요한 요소이다. 

단순히 하드웨어의 퍼포먼스를 향상시키는 방안이 아니라 자주 호출하는 SQL이나 프로그램에서 호출되는 SQL의 경로 등을 운영체제나 다른 미들웨어 영역까지 확장하여 주어진 자원을 범위로 성능을 향상시킬 수 있는 범위를 탐색하는 것이 중요하다. 

데이터베이스 튜닝의 3단계

데이터베이스 설계 튜닝 : 데이터베이스 설계단계에서 성능 고려 

데이터베이스 환경 튜닝 : 성능을 고려하여 메모리나 블록 크기 등을 지정 

SQL문장 튜닝 : 성능을 고려하여 SQL 작성하고 쿼리 문장을 수정 

데이터베이스 튜닝 왜 할까 ? 

데이터베이스 튜닝은 주어진 H/W 환경을 통해 처리량과 응답속도를 개선하기 위해 수행한다. 시스템 운영 중 다양한 애플리케이션의 도입과 데이터베이스 내 데이터량과 환경이 지속적으로 변화하고 또한 이를 호출하는 프로그램과

SQL이 잦은 수정을 거치게 되면 데이터베이스는 성능을 보장할 수 없다. 이에 따라 성능저하가 발생하면 

시스템의 안정과 사용자의 만족등을 위해 정기적인 데이터베이스 튜닝이 필요하다.

데이터베이스 튜닝 누가 할까 ?

데이터베이스 성능 튜닝은 다양한 업무 영역에서 실시 한다.

응용프로그램 설계자 : 응용시스템 영역에서 시스템 재디자인

응용프로그램 개발자 : SQL 문장 레벨에서 힌트를 수정하는 효율적인 SQL 쿼리문장 수정 

DBA : 비정상적인 시스템 수치를 모니터링하고 이와 관련한 DB 파라미터 수정 

H/W,S/W,OS 관리자 : 시스템 레벨에서 원인을 파악하고 환경을 개선하고자 패치 권고 

하지만 시스템 구조 자체를 건드는 일은 운영 서비스 전체의 광범위한 영향을 미칠 수 있으므로 문제를 탐색하고 

발생한 문제 지점만을 효율적으로 진단하고 해결할 수 있는 지엽적인 처방이 우선시 되어야 합니다.

데이터베이스 튜닝 언제 할까 ? 

데이터베이스 튜닝은 시스템 계획.분석 및 설계,개발 및 검수, 시스템 운영 전 단계에 걸쳐서 수행

다만 각 단계에 맞는 튜닝방은들이 있으며 시스템 설계단계에서 부터 적극적으로 성능을 고려하여야만 추후에 튜닝에 대한 이슈가 적어질 수 있다. 이에 따라 시스템 개발 그 자체에 목적을 두는 것이 아닌 효율적인 시스템을 설계하고 개발하는데 전념 해야 한다. 

시스템의 문제를 분석하고 성능 목표를 결정하고 튜닝을 실시한다. 데이터베이스 튜닝을 위해 OS,DB,WAS 등의 영역에서 시스템 레포팅을 참조할 수 있다. 이에 따라 성능이 떨어지는 프로그램을 발견하거나 특정시점이나 환경에 저하될 수 있는 상황 등을 탐지할 수 있다. 이에 문제를 정확히 분석하고 이를 원천적으로 해결할 수 있는 다양한 방법을 시도해볼 수 있다. 위에서 언급한 바와 같이 시스템 전체 영역에 영향을 미치는 경우 서비스에 정상적인 운영을 오히려 방해하는 경우가 생기므로 파급 영향을 함꼐 고려해야 한다. 

디비의 기본 쿼리란 ?? 

구글 번역으로 쿼리는 질문,문의하다라는 뜻이다.

질문의 답을 달라는 요청인 것 같다. ㅇㅅㅇ

쿼리는 데이터베이스에 하는 요청으로 데이터를 달라고 요청한다 ~ !! 

쿼리는 데이터베이스에게 특정한 데이터를 보여달라는 클라이언트의 요청을 말한다 ~ !! 

이에 쿼리문을 작성한다는 말은 데이터베이스에서 원하는 정보를 가져오는 코드를 작성한다의 뜻으로

이해하면 된다. 쿼리문을 잘 작성한다는 것은 데이터베이스에서 필요한 데이터를 발빠르게 접근하여

데이터를 능숙하게 핸들링한다는 말로도 볼 수 있다. 

서버랑 스토리지랑 연결한 것 

이중화는 Active-Active, Active-Stand_by의 2가지 형태로 구성 된다.

형태별로 구성예제 및 장애 처리 방법에 대해 구체적으로 확인해 보겠습니다.

Active-Stand by(DAS)

소규모의 사이트에서 일반적으로 사용되는 형태입니다. 평상시에는 하나의 서버로 운영을 하고, 그와 스펙이 비슷한 서버를 예비로 준비를 합니다. 메일서버는 OS영역과 Data영역이 물리적인 디스크가 분리되도록 관리합니다. 예비서버는 OS가 설치된 형태로 언제라도 부팅하면 바로 사용 할 수 있는 상태로 준비 합니다. 장애가 발생되면 관리자가 판단하여 예비서버로 서비스 해야 한다고 판단이 되면 메일 서버에서 Data영역의 디스크를 분리하여 예비서버로 이전한 후 예비서버로 서비스를 운영하면 됩니다. 형태는 저렴한 비용으로 이중화를 구성할 수 있지만, 시스템 장애 시간이 길고 안정성이 적은  방법 입니다.

Active-Active(SAN) // SAN을 주로 많이 씀 

SAN을 이용한 스토리지를 구축한 형태 입니다. SAN은 공유가 불가능하므로 사용자가 각 서버별로 고루 분산되도록 구성이 되고, 사용자는 자신이 속한 서버에서만 서비스를 이용할 수 있습니다. L4에 의해 랜덤하게 서버에 접근한 후 사용하는 자신이 속한 서버에서만 서비스를 이용할 수 있습니다. L4에 의해 랜덤하게 서버에 접근한 후 사용자 인증 후 자신의 메일서버로 REDIRECT되는 형태 입니다. 사용자의 HOST가 지정되므로 경우에 따라 한쪽 서버로 사용자가 몰리는 경우가 생길 수 있으므로, 사용자 생성 시 고루 분포되도록 유의해야 합니다. 장애가 발생하면 클러스터링 SW에 의해 감지가 되고 자동으로 서비스 절체 및 이전이 이루어 집니다. 클러스터링 SW중 하나인 HACMP의 방법을 예로 들자면 서버#1에 장애가 발생하면 HACMP의 자동 감지에 의해 서버#1의 IP,DISK등의 정보가 서버#2로 이전되어 서버#2에서 서버#2대로 서비스 하는 것 처럼 보이지만 실재론 1대로 서비스 하는 것 입니다. 이 방법은 클러스터링 SW,SAN관련 장비로 인해 많은 비용이 필요하지만 높은 수준의 안정성을 확보 할 수 있으므로 사용자가 많고 안정성을 우선하는 곳에서 추천하는 방법 입니다.

Active-Active(NFS)

NFS,NAS를 이용한 스토리지를 구축한 형태 입니다. 공유가 가능한 형태로서 모든 서버는 동일 스토리지를 공유하고 동일한 서비스를 제공하므로 사용자는 어느 서버에서든 서비스 이용이 가능합니다. L4에 의해 사용자를 load balancing해 주며 사용자 분산은 1/n(서버대수)에 가깝습니다. 사용자량이 폭주 할 때는 메일 SW가 설치된 서버를 추가 하는것으로 간단히 증설할 수 있습니다. L4에 의해 서버#1에 장애가 감지되면 L4는 더이상 사용자를 서버#1으로 연결시키지 않습니다. 서버#1의 장애가 복구되기 전까지 서버#2 또는 다른 메일서버들에 의해 서비스 됩니다. 이때의 분산은 1/(n-1)에 가까워 집니다. 서버에 문제가 있어서 몇 일 동안 AS를 받아야 하는 상황이라도 문제없이 서비스 됩니다. 쫌 더 여유가 된다면 그 동안 예비 서버를 추가하므로 예전과 동일한 수준의 서비스를 할 수도 있습니다. L4에 의해 장애가 감지되므로 즉각적인 Failover가 이루어 지므로 서비스 장애 시간을 매우 작게 줄일 수 있습니다. SAN에 비해 매우 저렴한 비용으로 높은 수준의 안정성을 얻을 수 있는 방법으로 메일 시스템의 이중화로 적극 추천합니다. 네트워크 기반으로 공유하는 방식이기 때문에 보안에 취약해 질 수 있습니다. 

창고 관리 시스템(WMS) 이란 ??

창고 관리 시스템은 창고 또는 배송 센터 관리를 지원하고 최적화하도록 설계된 응용 소프트웨어 입니다.

프로그램은 창고 안 밖의 제품 이동과 보관에 있어 시설 운영을 계획,구분,지원,감독,통제할 수 있습니다. 

WMS는 비즈니스의 전체 재고에 대한 가시성을 제공하며, 유통 센터에 매장 선반까지 공급망 이행 작업을 관리하는 소프트웨어 솔루션 입니다. 

WMS는 입고,적치,재고,피킹,출고 등 물류센터 프로세스 전체를 통합 관리하며 기업의 물류관리 및 운영 능력을 향상시킴으로써 경영자원의 유용한 활용과 기업 서비스 향상을 지원하는 시스템 입니다.

WMS는 창고 내에서 이루어지는 모든 창고업무(입고,로케이션,출고,이동,재물조사)를 신속 정확하게 관리하고 공급 채널(Supply Channel)과의 재고정보의 실시간 공유를 지원함으로써 창고를 효율적으로 운영할 수 있게 해줍니다.

WMS는 물류센터에서 화물을 관리하기 위한 모든 정보시스템의 총칭을 말한다. 따라서 WMS는 화물의 입출고 관리,재고관리,보관위치관리시스템,출고지시시스템과 픽킹시스템(DPS),합포장시스템(DAS),택배로 구성되어 있으며 이러한 시스템은 각 기업별로 물류관리의 목적 및 물류관리의 규모에 따라 채용하는 종류와 깊이가 다르다.

오늘날 IT분야의 진보는 물류센터의 효율화에도 영향을 미치고 있습니다. 물류센터의 업무개선을 통해 물류부문을 효율화시키고 비용을 삭감해, 고객만족을 향상시키기 위해서 보다 더 효율적인 시스템구축이 필요하게 됩니다. 

이와 같이 물류센터내의 업무효율화를 위해서 필요한 것이 WMS입니다. 

온라인 소비자들은 웹 애플리케이션이나 또는 모바일 애플리케이션을 이용해 언제 어디서나 신속하게 구매/주문/반품 등이 이루어지기를 원하고 있습니다. 이와 같은 요구를 충족시키기 위해 기업들은 주문 이행 업무를 최적화하는 물류 창고 관리 소프트웨어로 신속하게 대응할 수 있는 능력이 필요하다.

WMS는 오늘날 공급망을 준비한다. 재고 관리 및 주문 처리 서비스와 인터넷에 액세스할 수 있는 유일한 요구 사항인 스마트폰과 브라우저를 통해 사용 가능한 전체 재고에 대한 실시간 가시성을 제공합니다.

WMS 사용 목적 

1.정확한 재고수량관리 및 재고금액의 자동적 계산

2.재고의 실시간 확인관리 

3.보관면적의 효율성 극대화 

4.픽킹작업의 효율적 수행 

5.선입선출의 정확한 실시

6.픽킹작업의 정확도 향상

7.포장작업의 정확도 및 효율성 향상

8.다른 물류시스템과의 효율적인 연계 및 ERP와의 연계 

클라우드 기반 WMS 

인터넷 및 디지털 기술이 고객의 구매 방식을 완전히 변화시키면서 공급 시장이 와해되고 고객 구매 패턴이 변화되며 공급망에 복잡성이 가중되고 있기 때문에 주문 이행 업무는 디지털로 연결된 솔루션으로 이와 같은 변화를 지원해야 한다.

클라우드로 전환하면서 WMS는 실시간 가시성,확장성 및 시장 반응성을 제공하는 인터넷에 연결된 주문 이행 솔루션으로 온라인 소비자들에 대처하고 있습니다. 

기업들은 재고 처리 프로세스를 간소화하고 자동화하는 동시에 비용을 제어하기 위해 물류 창고 관리 소프트웨어에 투자하고 있습니다. 동적이며 쉽게 설정 가능한 강력한 WMS 시스템은 신속하고 비용 효과적인 구현을 위해 클라우드를 활용함으로써 다음과 감은 이점을 실현할 수 있습니다. 

> 운영 효율성 향상 클라우드에서 재고 처리를 관리하는 물류 창고 관리 소프트웨어를 통해 공급망은 재고와 운영에 대한 실시간 가시성을 확보하며 관련 기술을 이용해 고객이 구매에 참여하는 방법을 지원합니다. 

> 총소유비용(TCO) 절감,클라우드 기반 WMS의 구현을 통해 기업은 더 이상 유지 보수 및 업그레이드에 막대한 비용을 지불해야 한다는 우려 없이 비용을 제어할 수 있다.

> 고객 경험 향상, 더 빠른 주문 처리 시간으로 고객 경험과 비즈니스를 향상시킬 수 있습니다. 고객들은 언제 어디서나 구매를 실행할 수 있습니다. 클라우드 기반의 WMS는 기업들이 시장 동향에 따른 요구를 충족하도록 지원합니다. 

IPS(침입방지시스템)

IPS란 용어 그대로 침입방지시스템이다.

차세대 능동형 보안솔루션이라 불리는 IPS는 인터넷 웜 등의 악성코드 및 해킹에 기인한 유해트래픽을 차단해 주는 솔루션이다. IDS는 특정 패턴을 기반으로 공격자의 침입을 탐지하는 반면 IPS는 공격탐지를 뛰어넘어 탐지된 공격에 대해 웹 연결을 끊는 등 적극적으로 막아주는 솔루션이다.

IPS의 기술요소는 네트워크 기반과 호스트 기반으로 나눌 수 있다. 네트워크 기반 IPS는 방화벽처럼 네트워크에 인라인 모드로 설치돼 공격을 차단해주는 기능을 하고 호스트 IPS는 서버 애플리케이션을 담당하여 시큐어 OS와 비슷한 기능을 수행 한다.

네트워크 기반 IPS에 대한 수요가 많으며 호스트 기반 IPS 제품은 드물다. 대부분의 IPS라고 하면 네트워크 IPS로 NIPS를 지칭하고 대부분의 제품이 NIPS = IPS로 통칭한다. 

IPS는 IDS에서 한발 나아가 공격이 실제 피해를 주기 전에 미리 능동적으로 공격을 차단함으로써 공격 피해를 최소화할 수 있는 능동적 보안대책이라는 점이 가장 큰 장점이다. 

IPS는 OS나 애플리케이션의 취약점을 능동적으로 사전에 보완하고 비정상적인 트래픽이나 알려지지 않은 공격까지 차단할 수 있기 때문에 높은 보안을 제공해준다.

IPS의 가장 큰 특징은 기업 외부에서 내부 네트워크로의 침입 방지 하는 것이다.

IPS의 도입을 원하는 대부분의 기업들 목표 역시 외부 침입방지이며 효과 역시 유해 트래픽의 원천적인 차단.

그러면 외부 트래픽을 차단하는 방화벽과 외부 침입을 방지하는 IPS는 어떤 차이가 있을까 ?

보안시스템인 방화벽은 단순 차단 기능, 알려진 공격패턴 감시 등을 통해 공격을 감지하지만, ㄱ새로운 공격을 막기에는 역부족이다. 알려지지 않은 공격에 대한 탐지가 곤란하고 내부 공격자를 막기에도 어려움이 있다. 

침입탐지의 오판에 따른 시간,인적,재정 낭비도 문제점으로 지적된다. 이에 반해 IPS는 알려지지 않은 공격에 대해 적절하게 대응을 하며 명백한 공격은 사전 방어를 취한다. 

웜과 바이러스 등의 침입을 네트워크단에서 차단시킴으로 보안 인프라와 네트워크 영향을 제거하여 공격에 대한 사후 조사로 인해 소요되는 관리자 운영 부담을 없애주는 장점이 있다. 

IPS는 웜 바이러스와 해킹으로부터 유발되는 네트워크 서비스 장애로부터 벗어날 수 있고 부가적으로 유해한 트래픽을 사전 차단함으로써 인터넷 및 네트워크 자원의 효율적 사용을 통한 비용절감을 도모할 수 있다. 

IPS가 보다 지능적으로 작동되기 위한 중요한 특징은 '위험 인지'와 '시스템 인지'기능이다. 

IPS가 내부 시스템들에 대한 보안 취약성을 통한 위협 전파 가능성과 해당 시스템 보안 패치 유무까지 알고 있다면 

단순하게 보안 침입 경보만 알려주는 것이 아니라 상관 분석을 통하여 취약한 시스템에 이러한 공격이 관련 통보

네트워크 보안 플랫폼이 가져야 할 특징 

1 - 첫 번째 특징으로 '호스트 격리'와 'NAC와의 연동을 통한 보안정책 강제준수'

2 - 두 번째로는 '트래픽 제어 관리'

3 = '위험 인지' 및 '시스템 인지' 기능이다. 

IPS의 개요 

유해정보차단 시스템 

능동형 차단시스템

Worm,Dos차단 시스템 

IDS + Prevention 

1) Switch 기반 

    - WORM / DOS 알려지지 않은 공격 차단에 중심

    - 성능적인 측면을 강조 

    - 알려진 공격 차단 및 대응 기능 미비 

2) Firewall

    - 기존 ACL에 기반한 침입차단 기능에 알려진 WORM이나 DOS 공격 탐지 모듈 추가 

    - 유해정보차당 측면 강조 

3) IDS 기반 

    - 기존 IDS를 in-line mode로 동작하도록 일부 수정 

    - 알려진 공격 차단 및 대응 기능 강조 

    - 기존의 IDS가 가지는 높은 오탐율 및 관리의 어려움 상존

IPS/IDS/FW 비교

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 

고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공,지속적인 배포입니다. 

CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬")을 해결하기 위한 솔루션 이다.

CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공한다. 

이러한 구축 사례로 일반적으로 "CI/CD 파이프라인"이라 부르며 개발 및 운영팀의 애자일 방식 협력을 통해 지원된다.

CI와 CD의 차이점은 무엇일까요 ?

CI/CD는 약어로,몇 가지의 다른 의미를 가지고 있습니다. CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다. 

CI/CD의 "CD"는 지속적인 서비스 제공 및 또는 지속적인 배포를 의미하여 이 두 용어는 상호 교환적으로 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다. 

지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 줍니다. 지속적인 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 합니다. 

지속적인 배포(CD)란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용합니다. 

CI/CD는 지속적 통합 및 지속적 제공(CD)의 구축 사례만을 지칭할 때도 있고,지속적 통합,지속적 제공,지속적 배포라는 

3가지 구축 사례 모두를 의미하는 것일 수도 있습니다. 좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 합니다. 

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미합니다. 이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라집니다. 대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나갑니다. 

지속적 통합 

현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 합니다. 그러나 조직에서 특정한 날 "병합 하는 날"을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 됩니다. 이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 때문입니다. 이는 팀이 하나의 클라우드 기반 통합 개발 환경 사용에 동의하는 대신 각 개발자가 각자의 로컬 IDE를 커스터마이징하는 경우 더욱 복합적인 문제가 될 수 있습니다. 

CI를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 자주 수행할 수 있습니다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인합니다. 다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행합니다. 자동화된 테스트에서 기조 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있습니다. 

지속적 제공

CI의 빌드 자동화,유닛 및 통합 테스트 수행 후 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스합니다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 한다. 지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것 입니다. 

지속적 제공의 경우,코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 

코드 릴리스 자동화가 포함됩니다. 이 프로세스를 완료하면 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됩니다. 

지속적 배포

CI/CD 파이프라인의 마지막 단계는 지속적 배포입니다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화합니다. 프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없기에 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 합니다. 

출처 : CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정 (redhat.com)

출처 : https://tagilog.tistory.com/588

깃허브란 ?

Github는 소프트웨어 개발 프로젝트를 위한 소스코드 관리 서비스입니다. 소스 코드를 열람하고 간단한 버그 관리,

SNS 기능까지 갖추고 있어 개발자에게 없어서는 안될 서비스 입니다. GitHub를 사용하여 버전 관리를 실시하고 있는 기업도 다수 있습니다. 

깃허브를 사용하기 위해서 커밋과 푸시는 꼭 알아 둬야 하는 개념 

커밋 (commit) : 파일을 추가하거나 변경 내용을 저장소에 저장하는 작업

푸시 (push) : 파일을 추가하거나 변경 내용을 원격 저장소에 업로드하는 작업 

사전 지식 2 : 로컬 저장소와 원격 저장소 

저장소는 파일이나 디렉토리를 저장하는 장소입니다. 변경 이력을 관리하고자하는 디렉토리 등을 

저장소의 관리하에 두는 것으로, 그 디렉토리에 있는 파일 등의 변경 내역을 기록 할 수 있다. 

저장소는 자신의 컴퓨터에 있는 "로컬 저장소"고 서버 등 네트워크에 있는 "원격 저장소"의 2개소에 있습니다.

기본적으로 로컬 저장소에서 작업을 수행하고 그 결과를 원격 저장소에 저장하게 됩니다. 

사전 지식 3 : 브랜치 

소프트웨어 개발은 현재 출시하고 있는 버전의 유지 보수를 하면서 새로운 기능 추가 및 버그 수정을 할 수 있습니다. 

이러한 병렬로 수행되는 여러 버전 관리를 위해 Github에는 브랜치라는 기능이 있습니다. 

지점은 역사의 흐름을 분기하여 기록해 나가는 것 입니다. 분기 한 지점은 다른 지점의 영향을 받지 않기 때문에

같은 저장소에서 각 개발을 해 나갈 수 있습니다.

GitHub 사용법 

1번의 작성은 처음 한번 하고 2번에서 5번 반복 ~ !! 

기본적으로 작은 작업 단위를 커밋하고 어느 정도 작업이 일단락했을때 푸시를 하는 것이 일반적 

커밋 작업이 알기 쉽게 커밋 메시지를 남겨두면 로그를 따라가는 때 도움이 됩니다.

1. Github에 저장소 작성 (git init) 또는 복제 (git clone)

2. 파일의 작성, 편집

3. 파일의 생성/변경/삭제를 git 인덱스에 추가 (git add)

4. 변경 결과를 로컬 저장소에 커밋 (git commit)

5. 로컬 저장소를 푸쉬해 원격 저장소에 반영 (git push)

mkdir : 새로운 디렉토리를 만드는 명령 

cd : 디렉토리 이동하는 명령 

git init : Git 저장소를 새로 만드는 명령 

파일의 생성 / 변경 /삭제 git 인덱스에 추가 (git add)

hello.html 저장소에 커밋할 준비를 하기 위한 변경 내용을 임시로 저장할 위치

변경 결과를 로컬 저장소에 커밋 (git commit)

다음으로 인덱스에 추가 된 파일 커밋, 커밋은 파일이나 디렉토리의 추가 또는 변경을 저장소에 기록하는 작업 

git commit -m "new file"

이제 저장소에 파일 추가가 기록되었습니다. 파일이 추가되어 있는지 확인 

git status 

원격 저장소에 반영하기 전에 원격 저장소 정보 추가 

로컬 저장소를 밀어 원격 저장소에 반영 (git push)

로컬 저장소의 변경 사항을 GitHub에 있는 원격 저장소에 반여앟기 위해 다음 명령을 실행

git push origin master

GitHub의 사용자 이름과 암호를 입력하면 GitHub에 푸시하고 원격 저장소에 반영할 수 있습니다. 

작업이 끝났으면 github.com 페이지로 가서 파일이 잘 푸쉬 됐는지 확인 

브랜치 사용 

사전 지식에서도 소개했지만 분기는 동시에 이루어지는 여러 버전 관리를 할 수 있는 구조 

- 브랜치 생성, 이동

- 브랜치에서의 개발 작업 

- 브랜치에 푸시 

- 브랜치에서 풀 

- 브랜치 병합 

- 브랜치 삭제 

브랜치의 생성, 이동 

우선 현재 브랜치 목록을 살펴 보자 

git branch

실행 결과는 다음과 같다.

* master 

현재 브랜치에는 "*"가 붙는다. 이는 브랜치가 master 것이고 현재 브랜치도 master 임을 나타내는 것입니다.

subdir01이라는 브랜치 생성 

git branch subdir01 

지점 이동은 checkout 명령 사용 

git checkout subdir01

지점 만들기 및 이동 다음 명령으로 정리 

git checkout -b subdir01 - 이동 명령어

git merge subdir01 - 브랜치 결과 병합

git status 

저장소 상태를 확인하기 위해 사용하는 명령어 

현재 브랜치의 이름과 추가,변경된 파일 및 디렉토리 목록 표시 

git add 

파일이나 디렉토리를 인덱스에 추가하는데 사용하는 명령어 

추가 할 때 [file_pattern]에는 파일 및 디렉토리 이름을 직접하고있는 외에 "*.txt"처럼 와일드카드로 여러 대상을 지정할 수도 있습니다. 

git add [file_pattern]

git commit 

인덱스에 추가 된 파일이나 폴더의 내용을 저장소에 쓸 때 사용하는 명령어입니다. 옵션을 지정하지 않고 

이 명령을 실행하면 커밋 메시지를 작성하는 편집기를 시작합니다. 

편집기는 각각 다르기 때문에 쉽게 메시지를 지정하려면 -m 옵션을 붙인 후 큰 따옴표 안에 있는 메시지를 지정합니다. 

또한 -a 옵션을 지정하면 변경된 파일을 검색하고 인덱스에 추가하는 작업도 동시에 실시합니다. 

git commit -am "A first commit"

git branch 

브랜치에 대해 다양한 작업을 수행하기 위해 사용하는 명령어 입니다. 아래와 같이 사용합니다.

git branch : 브랜치 만들기 

git branch : 브랜치 목록보기 

git branch -d : 지정한 브랜치를 삭제 

git checkout 

로컬 저장소의 브랜치를 전환 할 때 사용하는 명령어 입니다. 

git checkout 

git log 

로컬 저장소의 커밋 히스토리를 탐색하는데 사용하는 명령 입니다.

-n 옵션 내역보기 수를 지정할 수 있습니다. 

git log -n 10

git grep 

저장소의 파일 내용에서 검색하고자 할 때 사용하는 명령어 입니다.

특정 단어가 포함 된 파일을 검색하고 해당 파일의 어디에 단어가 포함되어 있는지를 확인할 수 있습니다.

git grep "검색 단어" 

git clone 

기존 원격 저장소를 로컬에 다운로드하기 위하여 사용하는 명령어 입니다.

예를 들어, GitHub에 공개되는 저장소를 자신의 컴퓨터에 다운로드할때 사용합니다. 

git clone [url]

git remote 

원격 저장소를 조작하는데 사용하는 명령으로 아래와 같이 사용합니다. 

git remote : 원격 저장소의 이름 목록 표시 

git remote -v : 원격 저장소에 대한 자세한 목록보기 

git remote add : 원격 저장소를 추가 

git remote rm : 원격 저장소를 제거 

git reset 

로컬 저장소의 커밋을 취소하기 위하여 사용하는 명령어 입니다.

잘못 커밋하거나 수정 누락이 있을때 자주 사용 

git reset -soft HEAD 

git merge

현재 브랜치에 다른 지점에서 변경 사항을 병합하는데 사용하는 명령 

다음의 예에서 분기 bug-fix를 master 브랜치에 병합

git pull

브랜치의 변경 사항을 캡처하기 위해 사용하는 명령어 

로컬 저장소의 브랜치에 원격 저장소 origin의 master 브랜치를 가져옵니다. 

출처 : https://tagilog.tistory.com/377