레이블이 SCM-GIT인 게시물을 표시합니다. 모든 게시물 표시
레이블이 SCM-GIT인 게시물을 표시합니다. 모든 게시물 표시

11/22/2023

Github Action 확장사용

1. Github Action 확장사용법 

  • Github의 변경사항 정리 
Github에 최근 변경사항 및 관련부분들 정리 

  • Github Action 기본사용법 
Github Action 기본사용법 정리 (반드시 확인) 

  • Github Action 설명 Site
설명이 잘 되어있어, 아래 부분들을 Link 연결하며, 지금까지 나만 사용 못했나 보다. 


Runner(Virtual Machine)기반으로 Docker를 이용하여 사용할 수 있으며, 본인만의 Github Action도 구현가능하다. 
시간이 좀 더 되면 다시, CirCleCI의 Relese 기능과 관련부분도 같이 좀 더 봐야 할 것 같다.


1.1 Docker 이용하여 확장사용가능 

Docker를 기본적으로 이용할 줄 알면 아래의 사용법도 대충 알 것이라고 생가되어진다.
좀 세련되게 구성하고자 한다면 본인이 직접 Containter (Dockerfile)을 만들어서 등록 후 사용해도 좋다. 

  • Github Action 내부에서 Docker 와 Docker Hub 사용법 
Docker Hub를 통하여 사용하면 되겠으며, 본인 마음대로 만들어서 사용해보도록 하자.

  • Docker 기본 사용법 
Docker의 기본명령어와 사용법을 알아두도록 하자 

  • Docker Package 하여 Publish 방법 
Docker Hub에 Publish 하는 방법 



1.2 보안기능지원 


현재 Cloud 기반의 Devops CI/CD는 쿠버네티스(Kubernetes)기반으로 병렬(Parrell)로도 지원하도록 가는 추세이며, 
더불어 보안기능제공하는 DevOps에서 DevSecOps  변경되어 가는 것 같다. 

  • Github Action도 제공 
보안기능도 제공을 해주어서, 요즘 DevOps 에서 DevSecOps로 가는 것 같다.
글을 읽어보면, TOKEN방식으로 진행하는 것 같으며, 흐음, 아직 보안은 좀 더 강화되어야 할 것 같다.


1.3 각 시각화 및 문제해결 

  • Worklofw Monitor
Cloud로 진행하다 보니, 어디서 막히는지 그런 것을 Debuging 하려고 만들 것 같으며, 시각화도 너무 멋지다. 

  • Github Action Badge
Github의 REAME.md에 세련되게 아래의 Github 공식 Badge 정도는 넣어두도록하자.

Private repository는 Github에서 공식으로 제공되는 Badge 이외는 동작하지 않으므로 주의
e.g. 
![GitHub release](https://img.shields.io/github/release/JeonghunLee/lora_gateway.svg?style=flat-square)              
![GitHub Action](https://github.com/JeonghunLee/lora_gateway/actions/workflows/ccpp.yml/badge.svg)    


2. Github Runner 사용 

일단 Cloud에서 돌아가는 Virtual Machine이라고 생각하며 되겠으며, 이 기반에 각 OS를 설정하여 돌아 간다고 생각하면 되겠다.
각 Runner는 현재 Parallel로는 지원되지 않는 것 같으며, 다만 Github Manaul의 그림보면, Parallel로 되는 것 처럼 나온다.
대신, Runner 한개로 Docker 기반으로 Concurency하게 동작은 가능할 것 같다. 

이렇게 까지 사용할 분들이 있을지 모르지만, Build 속도 때문에, 상위부분은 민감한 부분일 수 있다. 
특히 만약 Yocto로 한다면, 좀 골치가 아플 것 같다. 나중에 해봐야 알겠지만 


2.1 Github Runner 사용 

나의 경우에는 Github Hosting Runner를 사용했지만 아래와 같이 별도로 등록하여 사용해도 괜찮은 것 같다.
나는 이것만으로도 만족하며, 각 요금제에 따라 동작하는 Runner(Virtual Machine)이 다르므로 확인해야 한다.



2.2 Self-hosted Runner 등록 후 사용 

나는 아직 테스트를 못했지만, 자기가 가지고 있는 Machin(Self-Hosted Runner) 역시 등록하여, 다양하게 기능을 제공해주고 있는 것 같다. 
나중에 별도로 DevOps 전용 서버가 있다면 등록하여 테스트 해보도록하자.

  • Self host Runner
나의 경우는 현재 Github에서 제공해주는 Runner(Virtual Machine)이용하지만, 본인의 Hosted Runner를 등록가능한 것 같다.

  • 반드시 확인 (제한사항들) 



3. Github Action 기본분석 및 사용방법  

Github에서 제공하는 Github Action만 사용가능한게 아니며, 본인이 원하면 원하대로 구성도 가능하다.
이 부분은 아래에서 Github 에서 제공하는 Github Action 과 Custom Github Action을 각 분석을 해보겠다. 

  • Github 에서 제공하는 Action 기능확인 
현재 Github에서 제공해주고 있는 Action 기능들을 확인.


  • Action Checkout
가장기본으로 사용하며, Git checkout 소스를 download하여 한 후 build를 진행 
사용방법은 release에 각 release version 존재하며 README.md에서 각 사용법을 알아두도록하자.


  • Action upload artifact
C/I를 build를 진행하여 나온 결과물을 Upload하는 것으로 사용방법은 RADME.md에서 각 사용법참조.


  • Action Github Release
최종 Github Release 로, Source 를 압축하여 Release하고, 변경관련정보를 같이 넣어 Github Release에서 확인가능.
더불어 Tag 와 release 이름도 넣어 진행가능하며 변경사항도 정리도 가능 


  • Action Github Release->Asset 
Github Release의 Asset에 별도로 File을 추가한다. (나의 경우 Binary File 추가)


  • 항상 Github Action 사용전에 
기본적으로 사용법을 알고 싶다면, 각 Github Action의 Site의 README.md를 확인하도록 하자.


3.1 Github Action 세부분석   

Github에서 제공하는 Github Action이며, 이를 좀 자세히 분석해보도록 하자. 
일단 위치는 https://github.com/actions 이곳에 있으며, 이 중 checkout을 비교 분석해보자.

  • action/checkout 분석 
action.yml 시작 점으로 각 Java Script을 과 이에 배포에 필요한 Package.json 확인해야 하는 것 같다.
Java Script을 완벽히 잘모르기 때문에 간단히 분석하며, 아래의 Custom Github Action 과 일단 다른 구조이다. 

action.yml 확인 
아래에서 실행되는 파일을 찾아서 보면, run의 dist/index.js 이며 , node.js 이고 HTTP Post방식같다.

dist/index.js 확인 
상위 run에서 실행되어지는 Java Script 

Node.js Package 작업시 같이 필요할 것 같아 Link만 연결  

일단 다 봐도 세련되게 Node.js로 구성한 것 같다. 


3.2 Github Action 사용법

이전 기본사용법에서도 봤듯이 workflow 구성한 후  Job 의 밑에 step을 두고, 각 사용하면된다.  

action/checkout 사용법


concurrency 로도 동작가능



3.3 Custom Github Action 구성

상위 Github에서 제공하는 Github Action만 사용가능한게 아니며, 본인의 Custom Github Action 구성도 가능하다.

  • Github Custom Action 지원 
기본으로 제공하는 Github Action 이외에도 본인 Container를 구성 후 만들어도 좋다.
DockerFile을 설정 후 EntryPoint 기반으로 구현하는 것으로 보인다. 


  • Github Custom Action 만드는 방법 
나도 아직 만들어 보지 못했지만, Github manual을 보면 쉽게 만들 것이라고 생각되어진다.
아래의 Github manual을 자세히 보고, 다른 예제를 보면 될것 같다.

STEP.1 Docker Container 생성 
Docker Container를 구성후 각 Entrypoint 설정과 관련 Script 이용
Python 이든 본인이 익숙한 언어로 구성하면 될 것 같다. 


STEP.2 hello-world-docker-action/action.yml 생성 
metafile이라고 하는데, yml로 쉽게 생성가능 


STEP.3 Docker의 Entrypoint 실행파일 
실제적인 Action Code라고 하며, 가장 중요 


STEP.4 README.md 파일에 사용법 
다른 것 처럼 README.md에 사용법을 적어놓도록하자. 


STEP.5 전체구성 확인 
Git으로 최종으로 잘 동작되면, Tag를 넣어, 올리고 전체구성을 다시 확인 


  • 만들어진 Custom Github Action 사용법 
이제 사용이 가능하며, 실제 사용방법은 espressif로 보면 될 것 같다.

    runs-on: ubuntu-latest
    name: A job to say hello
    steps:
      - name: Hello world action step
        id: hello
        uses: actions/hello-world-docker-action@v2

상위예제는 아래에 만들었을 경우인 것 같음 

개인 or 조직 
아래와 같이 개인 이나, 조직 기반으로 만들면, 상위에 한번 개인 or 조직이름만 추가해주면 되는 것 같음 


3.4 Espressif사 의 Custome Github Action 분석 

Espressif에서는 본인들의 Github Action을 확장하여 사용하고 있으며, 이를 간단히 분석가능하다. 
매번 느끼지만, Espressif에서 많은 것을 보고 배우며, 잘 만들었다. 
JIRA와 Github Project와도 Sync를 할 수 있도록 Github Action을 만들었으며, 다양하게 만들어서 예제로 좋은 것 같다.

  • Espressif 의 확장 Custom Github Action 
상위의 Custom Github Action Manual대로 만들었으며, 쉽게 이해가 가며 다양한 예제가 존재

  • Github 의 Project 의 Issue 들을 JIRA와 Sync 작업 및 기타 
예제가 너무 좋은 것 같으며, JIRA와 Github Project를 같이 사용하면 괜찮을 것 같다.
나의 경우는 현재 Github Project도 괜찮다. 
release zip으로 예제 

소스를 보면 쉽게 이해가 가며, 역시 잘 만들어 놓은 것 같다.
댓글 없음 :
Tags: , ,

11/21/2023

Github Action 기본사용법

1. Github 의 Cloud DevOps CI/CD 

이전에 간단히 Github의 Action을 간단히 소개했는데, 관련부분에 대해 좀 자세히 기술하도록 하겠다. 

Github의 변경사항 정리 
이전 Github의 최근 변경사항 정리 


1.1 Github Action 제한과요금제 

일단 Free 요금제도, 현재 거의 마음대로 사용가능한 것 같으며, 다만 시간과 각 부분이 제한이 있을 뿐이다.
Build 와 Deploy를 매번 할 필요도 없거니와, Free 요금제로도 현재는 IoT는 거의 쓸만한 것 같다.

다만 아래의 제한과 요금제를 반드시 확인하며, Github의 정책이 변경될지 모르니, 수시로 확인

  • Github Acton 의 제한 과 요금제  
현재 달마다 갯수로 제한을 하며, 각 요금제에 따라 반드시 확인 



1.2  Github Action 사용량 확인 

Github Action을 사용하면 각 사용부분을 확인하도록 하자 

  • Github 본인계정으로 Action 량 확인   
Github 본인 계정으로 Login 후, Setting-> Billing and Plans 

> Github Action 사용량확인 
Action , Package 뿐만 아니라, 각 Codespace 비롯하여 각 부분 사용량이 나옴 

> Github Action 제한방법
아래 Payment를 설정안하면, Action 부분도 설정못하므로 의미가 없음  

> 유료로 Github Action 사용할 경우, Payment 설정 
나의 경우는 설정안함 



2. Github의 Action 이란 

DevOps 의 CI/CD 하면 요즘 Cloud 기반으로 하는데, Github Action 역시 Runner(Virtual Machine) 기반으로 Cloud 사용하는 것 같다. 
이전에는 주로 나의 경우, CI/CD 이용한다면, Local/Cloud/Remote 기반이면 Jenkins or 무료/유료 Cloud기반이라면, CircleCI 많이 이용 했을 것이다.
이제는 Github에서 제공하는 Github Action로도 CI/CD 간단한 것들은 이곳에서 해도 괜찮은 것 같다. 

참고로, 이번에 CircleCI 로그인하니, 기능변경이 너무 많이 되어졌으며, 변경사항을 새로 알아야 할 것으로 생각되어진다. 
CircleCI로 사용할지도 다시 생각해야함(현재 무료사용자) 

  • Github Action 설명 
Github Action 부분은 Github에서 자세한 설명이 있으므로, 이것만 읽어도 알것이라 생각됨 


  • Github Action 전체구조 
기존에 사용하던, 다른 Script와 거의 유사하지만, 아래와 같이 Event를 별도로 정의하는게 가장 큰 특징으로 보인다. 
Cloud이므로, Virtual Machine 기반으로 각 사용하여 동작하며, 더불어 Docker까지 확장하여 사용가능하다. 
  1. Event :  Github의 Webhook로 Git에 대한 Event Callback 
  2. Runner1: Flowchart기반으로 각 실행1 진행 
  3. Runner2: Flowchart기반으로 각 실행1 진행 
https://docs.github.com/ko/actions/learn-github-actions/understanding-github-actions

  • Github Action 전체예제 
전체는 간단하게 YAML으로 Script로 작성하며, 간단하게 아래의 예제를 보도록하자.
자세히 설명을 해주어서, 내가 구지 설명을 해야할 정도로 쉽다. 

2.1 각 YAML Script 내부 필수 정보(workflow) 

Github에서 너무 자세히 설명해주어서, 내가 구지 설명을 안해도 될 거 같아 필요부분만 링크를 한다. 
각 Github Repository에 .github/workflow/xxxx.yml 로 Script을 구성하면된다. 

  • Github Action의 Workflow 기본적인 사용방법
Github Action을 만들때, Workflow 기본적으로 작성법 

  • Github Action 내부에서 사용되어지는 context
반드시 봐야하며, 각 YAML Script에서 사용되어지는 구문이므로 확인 

  • Github Action 내부 환경변수 사용 
Linux shell 에서 보통 많이 사용 



2.2 Action Event 기능 

이 부분은 이전에는 Webhook를 이용하여 사용하였는데, Github Action Script에서 쉽게 정의가 가능하다.
간단히 설명하면 다음과 같으며 주로 많이 사용할 것이 아마 Git Event일 것이다. 
  1. Git 의 관련된 Event
  2. Github 의 Issue Event
  3. Github 의 label Event 
  4. 기타 등등 

  • Webhook 관련내용 
일반적으로 Webhook는 주로 많이 볼 수 있는 것이 AWS Lamda 와 Github Webhook일 것 같다. 
Event가 일어날 경우, 이를 알려주는 API로 많이 사용되어지며, 아래의 내용을 참고하자. 


  • Github Action 의 Event 기능 
Event를 사용하는 다양한 방법을 소개하며, 상위의 Webhook의 기능이라고 볼수 있다.  

  • Github Single Event 실제예제 분석 
Github 의 Push Event가 발생할 경우, branches 조건 과 아래 tags 조건을 보고 Event를 동작한다.
상위 두 개 조건(branches/tags)을 And 연산하지 않고 OR 연산하여 동작하며, 이를 Filter 라고 함 
  1. Push 후 branches 이름 확인 
  2. Push 후 tags 이름 확인  
  on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:        
      - v2
      - v1.*

  • Github Action 다양한 각 Event 동작 예제들 
상위 내용은 workflow-trigger 전체설명 

Single Event 와 Multiple Events (e.g. push, fork, pull_request)

Filter 역할로 include 로 포함하여 OR연산으로 동작  (상위와 동일) 

Filter 역할로 exclude 로  제외도 가능(e.g. branches-ignore, paths-ignore) 

Github Action 다양한 확장 Event 기능 
다양한 Event Trigger 제공해고 있으며, 다 사용해보지 못했지만, 대충 이해가능 



2.3 Github Action 실제사용 예 

나의 경우, 간단히 테스트를 위해서 사용했으며, 잘 동작되는 것을 확인하였다. 
Event는 Github에 Push 될때,  Tag가 있을 경우에만 동작하도록 함 
즉 Release 목적으로만 만들었으며, 사실 오직 Github Action 테스트 하기 위해서 만듦
좀 더 고급스럽게 하며 Docker 기반으로 하면 된다.  




2.4 Github Action 실행동작 및 결과 

실제로 사용해보니, 꽤 좋으며, 확장하여 Docker기반으로도 사용가능하다. 

  • Github Virtual Machine 확인 
  https://docs.github.com/ko/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners


  • Github Action 진행과정 
Github Action에서 자동으로 CI가 진행 된 후 CD가 됨



  • Github Action 의 결과확인  
자동으로 Release가 되며, 상위 Script에서 내가 또 별도의 File도 추가하였다. 
아래와 같이 Github Action으로 되었다고 하며, 
내가 원하는 대로, 각 정도도 포함되어있으며, Assets도 별도로 추가한대로 추가되어져 있다. 




댓글 없음 :
Tags: , ,

11/17/2023

Github 최근 변화사항 정리

1. Github 변화사항 정리   

최근에 Github을 많이 사용하면서, 이전과 많이 변화 되어 진게 많아 각 부분을 간단히 정리한다.
사실 생기지는 다 오래되어진 기능이나, 최근에 변화를 많이 느끼는 것 같아 각 부분을 정리한다. 
또한 Github Setting 역시 이전과는 많이 변경되어졌다. 


Github Docs
설명서도 한글지원 된다. 


1.1 Github 의 보안인증강화 

  • Github 의 인증 2 단계인증 
나의 경우는 Beta일 때 부터 Google OTP를 이용하여 사용하였는데, 이제 거의 사용을 해야 하는 듯 하다. 
그리고, Android App 이름도 Google OTP에서 이제 Google Authenticator으로 변경되어졌다. 

Github 인증 


1.2 Github 의 Web-IDE 기능제공 

간단하게 Web Browser에서 VS Code 같은 IDE를 사용가능하며, 이외 다양한 IDE 확장제공을 해주고 있다. 
기능은 점점 확장되어지는 것으로 보여지며, 돌아가는 원리는 Web Browser에서 동작하는 Node-RED 생각하면 될 것 같다.  
내가 현재 좋아하는 Node.js로 구성을 했을 것 같다. 
(Node-RED 블로그 글도, 마무리해야하는데, 게을러서 못하고 있음)


  • Github의 Codespace 기능제공 
Cloud Web 기반의 Github에서 IDE Program인, VS Code를 사용할 수 있지만, 아직 초기단계라 거의 많이 지원이 안되어지며, 
자꾸 Web VS Code가 죽으며, 아직 VS Code Extension 도 너무 제한적이다. 
현재 시점이 지나서 좀 나아진 다음에 사용해도 안 늦을 것 같다. 

Github의 Codespace
Github에서 Cloud 기반으로 Virtual Machine 위에서 상위 VS Code 및 각 IDE를 제공해줌 
  
Github의 Web VS Code IDE 
VS Code 역시 node.js로 된걸로 알고 있으며, 이 것 역시 아마 Node.js 기반으로 돌아 갈것이라고 생각되어진다.

Github의 Web JetBrain IDE
사실이게 뭔지 몰라서, 사용해보고 있는데, 왠지 괜찮을 것 같다.
Jetbrain Site가면 각 IDE Tool 존재하여 나의 경우, CLion 사용했지만, 상위처럼 연결을 못함  


최근에는 Jupyter역시 많이 변경되어진 것 같으며, 이부분도 나중에 다시 확인해보도록 하겠다.

  • Github Codespace -> VS Code 
본인 Repository에 가서 우측 Code 버튼 -> Codespace에서 처음 한번 생성 한 후, VS Code 처럼 이용가능  
사용할때마다 더 VS Code가 개선되어지며, Extensions의 Program도 Upgrade되기 때문에 현재 그나마 좋음 

주의해야 할 것은 Cloud기반으로 하므로, 무료는 여러개를 동시에 사용이 안되어지는 것 같으며, 
Local VS Code와도 동기화가 된다고 한다.(이부분은 아직 못함) 
  

Github VS Code 세부내용 



1.3 Github 의 DevOps-CI/CD 기능확장 

  • Github Action 확장지원
옛날에는 Circle CI 기반으로 Webhook을 이용하여 사용했는데, 이제 Webhook 거의 필요가 없을 듯하다
각 Git Event도 Script 하나로 해결되어지니, 얼마나 편한가? (하지만 또 필요할지도?)

Github Action 기능에 많이 놀랬으며, 이거 가지고도 장난칠 게 너무 많다.
내가 원하면, 내가 원하는 Github Action도 확장하여 작성가능한 걸로 보일 뿐만 아니라, 
각 다른 언어들로 Github Action을 구성하여 만들 수 있는 걸로 보인다.
더불어 Docker 역시 맘대로 사용 가능한 것으로 보인다.   

가장 막강하게 변화되어진걸로 생각되어진다. 
누구나 쉽게 Cloud 기반으로 DevOps CI/CD를 이용하도록 하자.

Github Action CI/CD 구성 

Github Action 시작

Github Action 기반으로 Package 작업

Github Action 요금제

이부분은 누구나 쉽게 배울 수 있어, 추후 별도로 나중에 더 자세히 기술하겠다. 
현재 개인들에게는 무료로 제공을 해주는 것 같다 (현재 무료로 이용중이니)

Github Action 덕분에 최근 Circle CI를 들어가보니, 왠지 이거 때문에 Circle CI가 많은 변화가 있는 것 같다.
이제 Circle CI는 사용만 골치아플 뿐이지만, 추후 또 사용할 일 있다면 그때 다시 확인하자.


1.4 Github 의  Code 자동생성 

ChatGPT도 있는 마당에 내가 가장 기대하는 기능이지만, 무서운 기능으로 생각되어지며, 나중에 회사돈으로 사용할 일 있다면,
그때 사용하겠다. 

  • Github  Copilot 지원 
가장 기대되는 기능으로, 자동으로 Code를 작성해주는 기능으로  현재 무료가 아닌 것 같아, 함부로 사용을 못하지만,
현재 ChatGPT가 있으나, 궁금하기는 하다. 

Github Copilot 

Copilot 가격정책 



1.5 Github 의 기술블로그 및 Website 운영 

나의 경우는 별로 선호하지 않는 기능이며, 지금도 계속 변화 중이니, 나중에 다시 확인해보도록 하겠다. 
나도 대충하나 만들어놨으며, 별로 사용안한다. 

  • Github 의 Pages 기능확장 
각 기술블로그를 만들수 있으며, 사실 나는 선호하는지 않는다. 

Github Pages



1.6 Github 의 Project 관리와 문서관리  

  • Github 의 Project 기능제공  
Github 기반으로 Kanban 보드 부터 거의 JIRA 처럼 제공해주고 있으며, 지금도 계속 변화 중이다. 
현재는 지속적으로 사용안하지만, 개인적으로는 JIRA 만큼 기능제공해주고, 계속 변화 중이라,
나는 만족하며, 이전것은 Classic 이라고 하고, 또 새로운 버전 나왔다.  
각 기능은 아래 Manaul로 알아 보도록 하자. 

Github Project 
기본적으로 Project을 만들고 나서 아래 것들을 사용해야하며, 각 Issue와 label 및 Milestone도 별도로 사용가능하다. 

Github Issues
지속적으로 변경 중이며, 계속 Manual을 보도록~~~ (거의 JIRA처럼 사용가능)

Label 으로 구분 및 Milestone 기능확장 
꽤 괜찮은 것 같으며, 구분하기에 좋다 


  • Github 의 docs 와 wiki 문서관리 
Github에서 기본적으로 각 Repository에 README.md 기반으로 docs directory  만들어 각 Markdown기반으로 문서관리가 가능하다.  
이 뿐만 아니라, Wiki 와 이 Markdown의 확장부분을 보면되겠다. 
사실 사용하기가 좀 불편하기는 하지만, 무료로 사용한다는 점에서 강점이라고 생각되어진다.


Markdown 문서관리 
Github README.md 기반으로 docs 내부로 확장작성하여 문서작성가능. 

Markdown 기반으로 Diagram(Mermaid) 뿐만아니라 계속 다양하게 확장 중. 

이외 README.md에 Badge기능도 있으며, 이를 통해 각 연결된 Interface Website 결과도 쉽게 알수 있다. 

Github Wiki 
Github에서 Wiki를 지원 (요즘 거의 다 지원되니) 


Readthedoc 사용 
상위 docs Directory를 이용하여 쉽게 Readthedoc기반으로 문서관리 


1.7 Github 의 요금정책 

지속적으로 변경되어지니, 각 부분을 반드시 확인하도록 하자. 난 Free 요금제 

Billing and Plans
댓글 없음 :
Tags: , , ,

3/21/2022

VS Code Git 사용법 및 Merge

1. VS Code에서 Git 사용법 및 Merge  

VS Code기반으로 개발을 하다보니, Git도 자연스럽게 VS Code로 전부 해야 할 것 같아 관련자료들을 수집해보고, 테스트 해본다. 
VS Code에서 보면 주로 Source Control 와 GitLens로 이용하여 Git을 Control 하고 사용하는 것 같다. 

개인적으로 보면 GitLens는 잘 동작해서 좋기는 한데, 복잡해서 별로 사용하고 싶지가 않다.
난 소스트리 처럼 간단하고 심플한 기능으로 쉽게 동작되는 것이 너무 좋다. 
그래서 가능하다면, VS Code의 기본기능인 Source Control 이 GitLens보다 더 심플해서 이 기반으로 정리하려고 한다.  
항상 느끼지만, Git을 사용하다가 사용안하면 자꾸 명령어도 까먹는다. 


1.1 VS Code Version 기본 사용법  

  • VS Code 의 Source Control 준비 
VS Code의 Source Control 이동 후 Remote도 확인 가능하도록 아래와 같이 View를 확장 

아래그림 A. 버튼을 눌러 아래와 같이 Remote/Local 을 동시보도록 확장설정
  1. Source Control Repositories:  사실 Local 정보, 전체 Repository 를 Control, Remote Repostory를 쉽게 확인가능 
  2. Source Control: Local Source Git 정보, 주로 현재 소스 Control을 함 


상위그림 B. Git Graph: 각 Commit된 것을 Graph로 보여줌
상위그림 C. Branch:  Remote의 Branch로 정확하게 Checkout 기능


주의사항
상위 C. Branch를 선택하면 다른 Branch 와 tag가 나오는데, 이를 변경시 Checkout이 되어 소스가 변경되어진다. 


1.2 Git Checkout 방법 및 주의사항

  • Git Checkout 하기전 확인
상대방이 나 몰래 Remote에 Push를 했을 경우, 현재 나의 Local에는 이게 반영이 안되었으므로, 
반드시 Git Pull or Git Sync(Git Pull and Push)를 해줘야한다. 
그래야 SOURCE CONTROL REPOSITORIES 가 항상 Remote 와 동일해진다. 
Git 항상 다른 사람과 같이 작업하므로 이부분은 모든 부분에서 확인해야함 

  • Git Checkout 이란?
현재 수정 중 혹은 수정완료 후, 갑자기 다른 Commit or Branch 소스로 변경해서 각 소스를 확인해야 하는 경우가 발생한다. 
이때 다른 Git Commit or Git Branch으로 Local 소스변경하는 것이 Git Checkout이다. 


보통 VS Code에서 Checkout은 Git Graph 기반 와 상위 C.Branch 를 이용하여 사용하는 것이  가장 편한걸로 생각되어진다.

이때 새로 생성된 폴더와파일은 제거가 되지 않는 경우가 많으므로, 주의하도록 하자 


  • 방법-A  상위그림 C.Branch 선택시 할 경우 
Checkout 동일한 기능이지만, (Branch/Tag) 단위로만 이동되어지며, 쉽게 해당 Local 소스 변경되어진다. 
이전에 소스수정중이라면 반드시 주의해야하며 Backup용으로 새로받아 진행해도 된다. 

  • 방법-B  상위그림 B. Git Graph 기반의 만약 Commit 단위로 Checkout 
상위 B. Git Graph를 실행하여, 해당 원하는 Commit으로 찾아가 오른쪽 메뉴로 Checkout  현재 Local 소스변경하여 확인한다. 
이 역시 소스 수정중이라면 반드시 주의해야한다.   
 


이외에도 다양한 방법이 있겠지만, 나의 경우는 이게 편하다. 

1.3 Git Stash 기능 

Checkout을 하여 다른 것을 보고 싶은데, 현재 Commit을 해야할 File들이 있다면 이때 Git Stash를 이용하자.
이 임시파일들을 Git의 Stash에 저장하고, Checkout하고 나서 변경되어진 Commit or Branch에 이를 적용가능하다. 

  • Git Stash 의 예
내가 소스를 수정중인 File들을 임시적으로 저장하는 기능이 바로 Git Stash 기능이며, 나의 경우 
주로 Git checkout 을 한 다음 그 Version 이 Git Stash이를 이용하여 적용을 한다. 
VS Code에서 사용할 경우, STASHES라는 곳에서 확인가능 


2. VS Code에서 Git Merge 방법정리  

  • Git Merge 하기전 확인
상대방이 Remote에 Push를 했을 경우, 현재 나의 Local에는 이게 반영이 안되었으므로, 
반드시 Git Pull or Git Sync(Git Pull and Push)를 해줘야한다. 
그래야 SOURCE CONTROL REPOSITORIES 가 항상 Remote 와 동일해진다. 
Git 항상 다른 사람과 같이 작업하므로 이부분은 모든 부분에서 확인해야함 

  • Git Merge 방법 
Git Merge에도 방법이 있으며, 아래와 같이 간단히 정리한다.  
  1. 현재 Branch의 특정 Commit들만 (Cherry-pick)적용하여 다른 Branch에 Merge 적용 
  2. 현재 Branch 와 다른 Branch Merge   (각 Branch 단위로 Merge 진행)

2.1 VS Code 에서 특정 Commit 만 Merge 방법 

git cherry-pick command를 사용하며 특정 Commit 만 Merge방법 

Cherry Pick Merge라고 하며아래와 같이 특정 Commit만 찾아 Merge를 진행. 
  • 좌측 release branch  : 
    • develop branch에서 필요한 것만 가져와서 최종 Release 할것 
  • 우측 develop branch : 
    • Commit F  : 넘어감 
    • Commit E  : 이것만 반영  
    • Commit D : 넘어감 
    • Commit C : 원래 Commit C 반영할 차례(빨간색)지만, Commit E만 반영할 예정 
    • Commit B : 이미 Release 반영 
    • Commit A : 이미 Release 반영 

Commit D는 생략 
Commit E 만 release 에 merge 하고 싶을 경우 아래와 같이 cherry-pick 사용 


https://geekwebcast.com/git-cherry-picking-with-vs-code-part-1/


https://geekwebcast.com/git-cherry-picking-with-vs-code-part-1/


상위그림 B. Git Graph 화면으로이동 
  1. Branch Show All
  2. Show Remote Branches 체크 확인  
  3. Refresh Button (Sync)  

만약 특정 Branch만 보고자 하면 해당 Branch만 선택

  • Git Graph 에서 원하는 Commit을 찾기  
    1. 상위 Git Graph를 두군데서 확인가능 (Remote 와 Local)
    2. 항상 현재 사용중인 Branch가 맨 좌측에 위치 (현재 develop)
    3. Local 와 Remote 의 Commit History가 다르다면, Synchronize Change를 맟춰줘서 동일하게 보도록한다.
Git Graph에서도 항상 Current Branch가 맨 왼쪽에 나옴  

  1. Git Graph에서 원하는 Develop Branch에서 원하는 Commit을 찾음 
  2. 우측 눌러 Cherry-pick 선택 


Cherry Pick 선택하면 Yes Cherry Pick 선택 후 진행 (옵션무시)


조건사항-1. Cherry Pick Merge를 진행하는데, 소스상에서 겹치는 부분이 없다면, 
아래와 같이 Sync Changes 2 (Cherry Pick 갯수) 확인 
바로 자동으로 Merge진행 



조건사항-2. Merge를 진행하는데, 소스상에서 겹치는 부분이 있다면,
아래 Branch Merge와 거의 동일 


모든 기준은 상위에서 설정한 Current Branch기준 
Current Branch에 Merge 된 것을 확인 


세부내용 출처 (아래 링크 참조) 


2.2 VS Code Branch Merge 방법 

Git Merge를 할 경우, 
Bracn Merge 이든, Cherry-Pick 이든, 1개 File에서 기존 것 과 새로운 것이 겹치면 항상 선택을 해야한다. 
Merge Changes-> 각 파일  
  1. Accept Current Change: 기존 그대로 유지 
  2. Accept Incoming Change: 새로 적용된 것으로 변경 
  3. Accept Both Change: 두개를 다 적용 
  4. Comare Changes: 변경사항 비교 
    

1. Merge Changes 확인 



2. Merge Changes -> .gitignore 확인 
  1. 대부분 새로운것을 대체하여 사용하므로 Accept Incoming Change로 변경
  2. 기존것을 유지하고자 하면 Accept Current Change 진행  



3. Github 의 Release 방법(Tag) 

VS Code에서 Tag를 할수도 있겠지만, 나의 경우는 Github를 사용할 경우, 직접 Github에서 Tag를 하는 것을 선호하는 편이다.
이유는 Release시 Git에서 Tag하는 것 보다 편하며, 직접 필요한 파일도 추가가능할 뿐아니라, 추후 수정관리하기도 좋다.
 
최종 Release 할 경우, Target Branch을 선택하여 정해야 하므로 
미리 VS Code에서 본인의 Git History(View Graph로 확인)

  • Github Release Menu
  1. Github의 소스에서 Release로 이동 
  2. 우측 draft a new releae 선택 

  • Draft a new release Menu
  1. 좌측 choose a tag 버튼선택  
  2. choose a tag 의 빈공간 (Find or Create a new tag)
    1. release/v1.xxxx or v1.xxxx 새로이름 Tag 생성
  3. Target 선택 (release 할 branch or commit 위치) 
  4. Release Title 작성
    1.  Release v1.x.x 
  5. 내용은 Markdown이 되므로 되도록 Markdown Rule로 적용가능
    1. ** v1.x.x **

    3. ** Features and Enhancements **
    4.    A. updated something 
    5.    B. added new function related to something

    7. **Fix Bugs **
    8.    A. fixed the bug related to something 
  6. Preview로 반드시 확인  
    1. 상위 작성된 Markdown Preview 확인 
  7. Attach binaries  (옵션)
    1. 기본으로 Assets 에 Source는 zip 과 tar.gz 제공
    2. 이외 Binary를 추가로 넣을 경우, Releae Binary 와 OTA Binary  



Asset (Target기반으로 Source Code zip/tar.gz 파일제공 ) 

상위 내용은 추후  Release 후에도 수정도 가능하므로 실수해도 괜찮다.  


4. Git 기반의 기타기능들 

VS Code 기본 메뉴에서 Explorer 에서 각 File을 우측클릭메뉴 기능 

  • VS Code File 우측 메뉴
일반 File 과 비교할 경우 
  1. compare with selected 
  2. select for compare 
Git 관련 Command 
  1. commit changes  (다른 commit 과 branch와 비교) 
  2. open file history  ( File 변경사항들만 있는 Commit 전부확인)
  3. open Timeline  (Commit 과 File Save History까지 확인가능)
  4. Git: View File History ( 전체를 쉽게 보지만, Git Graph를 더 추천)



5. VS Code의 필요기능정리  


VS Code를 사용하면 , 많은기능들이 제공하는데, 보통 단축키로 제공으로만 제공해주는 것들이 많은 것 같다. 
매번 까먹어서 다시 링크로 넣어두도록 한다. 

  • VS Code 관련 단축키 확인 
Code 정렬시 사용하며, 좌측/우측 (가장많이 사용)
Line Shift   ( Ctrl+[ , Ctrol+] )

  • VS Code 의 laucnch.json 사용법
VS Code의 Run and Debug에 연결하여 사용가능하다.
.vscode 안에 넣어두면된다. 

  • VS Code의 Task.json 사용법
Powershell 기반으로 이용가능하므로 이용하도록하자.


댓글 없음 :
Tags: ,

12/04/2020

Gerrit(Git Review)

1. Gerrit(Git Review) 

이전부터 Git Review의 기능 궁금했는데 정확한 사용용도를 잘 몰랐으며, 최근 다시 repo를 사용하면서 다시 용도가 궁금하여 정리하려고 
검색했더니, 너무 많은 좋은 자료들이 많아 사용용도를 쉽게 알게되었다. 

아래 글을 읽어보면, 프로그래머의 Source를 Review하여, Source를 관리해주는 기능으로 보이며, 사용해보지는 않았지만, 
대충 이기능으로 회사마다 조금씩 정형화된 Code Convention 기능을 지킬수 있는 기능으로 보이며,  
더불어 글을 읽어보면, Source에 점수 주어 관리한다고 하는데, 어떻게 소스를 자세히 검토하는지와 문제가 되는 코드들을 찾아 
자동으로 검토를 해준다고 하니, 각 기능들이 궁금하다. 

별도로 추가도 소스검증기능도 가능할 것 같은데, 나중에 시간이 되면 한번 설치를 해보고 사용을 해봐야 자세히 알것 같다. 

네이버의 Git Review 자세한 설명 
  https://d2.naver.com/helloworld/6033708

Git Review , Code Review라는 기능이라고 하는데, 검색을 더 해보고, 곰곰히 생각을 해보면, 소규모 프로젝트에는 필요는 없을 것 같다.


1.1 Google의 Gerrit 기본구조

우선 두명의 개발자 개발하고 공인된 Repository를 공유한다고 한 후 이를 CI를 Jenkins로 별도의 Build Server로 사용하면 구성될 것이다.
네이버는 CI를 Jenkins로 위주로 구성했다고 한다. 
구글은 CI를 Jenkins 대신 Bazel을 사용한다고 하는데, 아직 사용을 해보지 못했다. 


https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html



개발자는 Push로 고친소스를 올리면, Reviewer 이를 받아 확인 후 검증하고 최종적으로 Submit되는 구조이다.
Reviewer들은 Google을 보면 같이 일하는 Co-Worker들인 것으로 보이는데, 많은 Reviewer들이 존재하며 어떻게 선정이 되는지 구성단계가 궁금하다.
본인이 원하는 사람에게만 Review를 하는 것인지, 아니면, 단계가 별도로 존재하는지, 기타 등등 부분이 궁금하다. 


https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html


Gerrit(Git Review)를 사용하고자 하면 상위와 같이 Git Repository 와 Gerrit(Git Review)가 같이 존재해야하는데, 
Github와 같이 외부 Repository를 사용한다면, 그 방법도 알아야 할 것 같은데, Github도 보면 Code Review 기능을 별도로 제공해주고 있다.

Code Review로 각 검색을 해보면, 각각의 Gitlab / Bitbucket / Github 다 존재하는 것으로 보인다. 

Gerrit(Git Review) 동작그림


1.2 AOSP(Android Open Source Project) Review

우선 Google에서 어떻게 사용하는지 궁금해서 아래 사이트를 전부 가입 후 Code Review 기능을 확인 
AOSP를 보면 CHANGE 구성에 따라 Open / Merge/ Abandoned 되는데, 각 변화마다 Code Review를 하도록 한다. 

  1. Open: Code를 수정하여 제안 
  2. Merge: 두 개의 Branch들을 합치는 것 
  3. Abandoned: 삭제되는 부분 (생략)

  • CHANGE->OPEN 기능 (기능추가하여 넣어 Review 단계)
각 개발자가 소스를 수정하여, 각 옵션을 설정후 수정된 소스를 Reviewer에게 제안하는 단계로 보인다. 



  • CHANGE->OPEN-> Subject (각 세부이슈)
구글의 Android Gerrit를 보면 reviewr가 한명이 아니라 보통 1명 이상으로 구성으로 하는 것 같으며, 여러개의 옵션이 존재한다  


https://android-review.googlesource.com/c/platform/frameworks/base/+/1502382

상위는 각 이슈에 대한 부분이며, 각 기능은 정확하게 다 파악하지 못했지만, 자동 Submit 부터 이를 검증 그리고, 
LINT 사용여부 비롯하여 다양한 사람에게 Review를 통해 검증부터 우측에 연관된 부분을 우측에 링크를 비롯하여, 
아래에는 이 이슈에대한 소스의 히스토리를 제공해주고 있다. 

구조를 보면, 자동소스 검토는 LINT 와 Treehugger Robot 사용하는 것으로 보이며, 많은 동료들이 검증 하는 것으로 보이며, 
Gerrit이 소스 검토를 비롯하여, 각 기능에 대한 좋은 Community 역할을 해주는 것으로 보인다. 


  • CHANGE->MERGE  
각 개발자가 소스 Confirm이 되고 최종적으로 두 개의 Branch가 각각 Merge할 것이며, 이를  Reviewer 설정하여 이를 점검한다. 



  • CHANGE->MERGE->Subject (각 이슈)  
각 개발자가 소스 Confirm되었고, 이를 실제 하나로 합치는 작업인데, 주로 이부분에서 많은 문제가 발생할것이다. 
개별소스는 각 테스트를 했으나, 소스가 합쳐지면서 생기는 문제들이 주로 일텐데, 이런부분도 각 Review를 통해 하는 것으로 보인다. 



Treehugger Robot
Git의 Tree를 관리해주는 Robot으로 보이는데, 추후에 직접 Gerrit를 설치 후 기본으로 들어있는지 외부 Robot인지 봐야 할 것 같음 

LINT
소스검증 Tool로 이용이 되며, Google에서 사용중 


Android Git Review System 확인
  https://android-review.googlesource.com/

Gerrit Git Review 확인 

AOSP(Android Open Source Project)


1.3 Repo 설명 

Repo 사용법은 아래의 Google Manual을 보면 될 것 같으며, 추후 분석은 아래 예제를 보면 될 것 같다. 
추후 Repo 기반으로 Project를 관리를 할 경우 나중에 다시 한번 제대로 세부사용법을 자세히 알야하 할 것 같다. 


Repo 사용예제 


1.4  GIT 관리 와 Gerrit 관리 문서 


구글문서들로 Git에 대한 기본 Concep 부터 세부문제사항에 대한 예제가 자세히 설명되어있으며, Gerrit에 대한 실제 사용법 및 예제가 나와있다. 

정리가 너무 잘되어 있어 보기 및 이해하기가 더욱 수월하지만, 막상 사용하려면 골치 아픈것 같다. 

Git explained: Git Concepts and Workflows (필독 및 이해)


2. Gerrit 설치 및 기본실행 확인


현재 Gerrit 의 필요성은 거의 없지만, 일단 설치 해보고, 실행하여 구성을 확인을 해보자. 

  • 설치전 확인사항 
  1. Open JDK 설치
  2. Hostname 설정 


  • Gerrit  기본설치 
Google의 Gerrit 메뉴얼대로 간단하게 설치 및 테스트

$ wget https://gerrit-releases.storage.googleapis.com/gerrit-3.1.3.war 

$ mkdir gerrit_test
$ 
$ export GERRIT_SITE=`pwd`/gerrit_test
$ echo $GERRIT_SITE

// 실행 후 GERRIT_SITE에 각 파일 및 관련구성이 설치되며 제대로 되면, 아래 Config의 HTTP로 접속가능 
$ sudo java -jar gerrit*.war init --batch --dev -d $GERRIT_SITE

$ ls gerrit_test/  // 자동생성되며, 아래 설정도 자동으로됨 
bin  cache  data  db  etc  git  index  lib  logs  plugins  static  tmp

$ tree -d -L 3 --charset unicode gerrit_test   // Gerrit 의 기본구조 
.
|-- bin     // Gerrit 의 Service 기능 
|-- cache   // Gerrit 의 Cache  
|-- data
|-- db       // Gerrit 의 DataBase로 Account 관리 
|-- etc      // Gerrit 의 설정부분 
|   `-- mail
|-- git             // Gerrit 의 BasePath 설정되며, git 정보만 생성됨
|   |-- All-Projects.git
|   |   |-- branches
|   |   |-- hooks
|   |   |-- logs
|   |   |-- objects
|   |   `-- refs
|   `-- All-Users.git
|       |-- branches
|       |-- hooks
|       |-- logs
|       |-- objects
|       `-- refs
|-- index
|   |-- accounts_0011
|   |-- changes_0057
|   |   |-- closed
|   |   `-- open
|   |-- groups_0008
|   `-- projects_0004
|-- lib
|-- logs
|-- plugins
|-- static
`-- tmp
    `-- gerrit_7861426947991176346_app

  • 설치된 Gerrit 기본실행확인 
상위 ASOP Git Review 와 거의 유사한 구조로 구성되어 실행됨



  • 상위 Sin in Admin으로 로그인 후 Repository에서 각 TEST Project 생성 
Repository를 추가하면,  상위 git directory에 Git 새로 생성되고, 관리가 시작되며, 생성시 아래와 같이 다양한 옵션들을 줄 수 있다.  



  • Gerrit Project 생성법 
basepath는 상위 git 디렉토리를 말하며, 그 기반으로 생성 

  • Gerrit Project 생성후 기본사용법
Gerrit의 기본 사용법인 것 같으며, 이 기반으로 추후 사용해봐야 할 것 같다.


  • Gerrit 전체설정 확인 
설정을 변경한 후에는 반드시 gerrit를 restart 해줘야함 
//hostname:8080으로 접속가능 및 기본 Project는 git 
$ cat  $GERRIT_SITE/etc/gerrit.config  // 자동생성되며, 아래 설정도 이미 JDK 와 Hostname을 설정했음 
[gerrit]
        basePath = git
        canonicalWebUrl = http://voyage:8080/
        serverId = 122d56c1-e454-4468-b7f0-68bc8c27f593
[container]
        javaOptions = "-Dflogger.backend_factory=com.google.common.flogger.backend.log4j.Log4jBackendFactory#getInstance"
        javaOptions = "-Dflogger.logging_context=com.google.gerrit.server.logging.LoggingContext#getInstance"
        user = jhlee
        javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
[index]
        type = lucene
[auth]
        type = DEVELOPMENT_BECOME_ANY_ACCOUNT
[receive]
        enableSignedPush = false
[sendemail]
        smtpServer = localhost
[sshd]
        listenAddress = *:29418
[httpd]
        listenUrl = http://*:8080/
[cache]
        directory = cache
[plugins]
        allowRemoteAdmin = true


Google Gerrit(Git Review) Config


  • Gerrit Service 기본제어 
아래 처럼 쉽게 gerrit.sh Service를 제어가 가능하며, 부팅시 자동실행하고자 하면 init Script에 추가 
// Gerrit Service 중단/시작/재시작
$ $GERRIT_SITE/bin/gerrit.sh stop
$ $GERRIT_SITE/bin/gerrit.sh start
$ $GERRIT_SITE/bin/gerrit.sh restart


기본 Quick Gudide를 보면 될 것이며, Install Guid에서 세부내용을 확인 
Gerrit PlugIn들  

2.3 Gerrit 의 Github 연결 

  • Github 사용자를 위한 Gerrit연결방법
상위와 같이 Gerrit를 설치 후 Gerrit 과 외부 Github를 연결하는 방법은 보면, 중간에서 Git을 가로채서 Git 명령어를 수행하여, 
이를 Gerrit이 모두 Github의 최종 Push권한을 갖는 것으로 보이며, 
.git/config 과 git Pull Request (Gerrit에서 지원못함) 부분을 좀 더 확인을 해봐야 할 것 같다. 


  • Github 사용자 위한 Gerrit  
별도의 Gerrit을 설치 없이 사용가능한 것 같은데, 너무 느려서 사용하기를 포기 
  http://gerrithub.io/

  • Github의 Code Review 기능
Github 이외 Gitlab 비롯하여 각각의 Code Review 기능을 제공하고 있으며, 이 기능을 사용하면 될 것 같다. 

댓글 없음 :
Tags: , ,
피드 구독하기: 글 ( Atom )