작업 - 간단한 구축을 위한 편리한 도구

Shamaazi에서 우리는 줄곧 task 라는 도구를 사용하고 있다.이것은 Makefiles (오래된 C 구축 시스템) 나 복잡한 스크립트를 완전히 대체할 수 있는 매우 강력한 도구이다.그 외에 명령행과 관련된 모든 활동에 매우 유용한 조직자이다.
Shamaazi에서, 우리는 7개의 다른 UI, 수백 개의 서비스와 우리의 모든 인프라 시설 설정을 포함하는 단일한 코드 라이브러리를 가지고 있습니다.저희는 task를 사용하여 이 모든 것을 관리하고 요청할 때 사용자 데이터를 삭제하거나 연락처 주소를 변경하는 등 내무 관리를 수행합니다.우리는 그것이 매우 강하다는 것을 발견했다. 왜냐하면 설정을 쉽게 읽고, 자기 기록을 할 수 있으며, 실행이 필요한 명령만 실행할 수 있기 때문이다. 이 모든 것은 구축, 검색 명령, 편집 설정을 기다리는 시간을 많이 절약할 수 있기 때문이다.그것은 작은 코드 라이브러리에서도 마찬가지로 가치가 있다.task가 무엇인지, 그리고 그 기능을 빠르게 탐색해 봅시다.

개시하다
가장 간단한 설치 방법task은 그들이 제공한 설치 스크립트를 통해서다.

curl -sL https://taskfile.dev/install.sh | sh

그러나 그것을 설치하는 데는 brew,snap 또는 scoop 등 다른 방법도 많다.그것들을 찾을 수 있다here.
일단 설치되면, 우리는 명령을 내리고 싶은 디렉터리에서 실행할 수 있다. task --init이것은 간단한 Taskfile.yml 파일을 만들 것입니다.이 파일은 매우 유행하는 사람이 읽을 수 있는 파일 형식인 YAML 형식을 채택하고 있다.이 Taskfile.yml 파일은 우리가 실행하고자 하는 모든 가능한 작업을 정의하는 데 사용됩니다.처음에, 그것은 단지 하나의 Hello, World! 예시만을 포함했다.

# https://taskfile.dev

version: '3'

vars:
  GREETING: Hello, World!

tasks:
  default
    cmds:
      - echo "{{.GREETING}}"
    silent: true

실행 task (또는 task default 은 위에서 정의한 default 작업, 즉 인쇄 Hello, World! 를 실행합니다.우리는 파일을 몇 개의 명확한 부분으로 분해할 수 있다.

version: '3' - 사용할 Taskfile 버전을 정의합니다.우리는 너무 많은 관심을 필요로 하지 않지만,
향후 버전에서 작업 중지를 방지합니다.

vars: - 이 섹션에서는 전역 액세스 가능 변수를 정의합니다.우리는 하나의 변수를 볼 수 있다.GREETING는 Hello, World!로 정의됩니다.이 변수들은 매우 강해서 다른 변수를 인용할 수 있고,
또는 명령의 출력에서 완전히 파생될 수 있습니다.

tasks: - 이 절에서는 실제 작업을 정의합니다.지금 저희가 미션이 하나밖에 없어요.default . 이 작업을 실행하면 명령echo "{{.GREETING}}"이 실행됩니다.silent: true 줄은 실행 중인 명령을 인쇄하는 것을 방지할 뿐입니다.

이것은 매우 빠른 소개다.하지만 더 강력한 기능을 소개해 드리겠습니다.

변량
이전 절에서 GREETING 변수는 명령의 출력에서 파생될 수 있다고 언급했다.때때로, 이것은 즉각 얻을 수 없는 정보를 얻는 데 매우 유용하다.간단한 예를 들어 task 섹션을 다음과 같이 변경합니다.

vars:
  GREETING:
    sh: echo "Hello, $(whoami)!"

현재 실행 vars 하면 출력 task (또는 사용자 이름이 무엇이든지 상관없습니다!) 을 출력합니다.그것이 명령을 집행할 때, 그것은 무엇이든지 될 수 있다.날씨Hello, dglsparsons!를 제공하고 jq를 사용하여 빠른 출력을 얻을 수 있습니다.그런 다음 두 번째 임무에 추가할 수 있습니다.

vars:
  GREETING:
    sh: echo "Hello, $(whoami)!"
  WEATHER:
    sh: curl -s wttr.in?format=j1 | jq -r .current_condition[0].weatherDesc[0].value

tasks:
  default:
    cmds:
      - echo "{{.GREETING}}"
    silent: true
  weather:
    cmds:
      - echo "There be {{.WEATHER}}"
    silent: true

런닝wttr.in은 지금도 같은 인사말을 출력한다.그러나 런닝task은 다음과 같은 내용을 인쇄합니다.

There be Haze.

이것은 매우 빠르고 쉽다.이제 우리는 이 명령을 잊을 수 없는 곳에 영원히 보존했다.

문서
따라서 우리의 임무는 유용하지만, 그들이 한 일을 설명하면 더욱 유용할 것이다.그것들을 위해 간단한 설명을 추가합시다.이것은 모든 퀘스트의 task weather 키를 통해 완성할 수 있다.

tasks:
  default:
    desc: Prints a greeting.
    cmds:
      - echo "{{.GREETING}}"
    silent: true
  weather:
    desc: Prints out the current weather.
    cmds:
      - echo "There be {{.WEATHER}}"
    silent: true

우리는 현재 desc 또는 task -l를 실행하여 모든 사용 가능한 작업의 간편한 요약을 표시할 수 있다.

$ task --list
task: Available tasks for this project:
* default:  Prints a greeting.
* weather:  Prints out the current weather.

이것은 이후의 임무를 더욱 쉽게 기억할 수 있게 한다.

의존 관계
우리가 보고 싶은 모든 일기예보를 다운로드하지 않고 일기예보를 파일에 쓰는 작업을 만듭니다.

vars:
  GREETING:
    sh: echo "Hello, $(whoami)!"
  WEATHER_FILE: weather.json

tasks:
  default:
    desc: Prints a greeting.
    cmds:
      - echo "{{.GREETING}}"
    silent: true
  download-weather:
    desc: Downloads a weather forecast into a file
    cmds:
      - curl -s wttr.in?format=j1 > {{.WEATHER_FILE}}

이것은 좋은 시작이지만 런닝task --list은 시종일관 다운로드 예측을 할 것이다.만약 우리가 어떤 파일을 입력으로 사용한다면, 당신은 그것을 download-weather 로 설정할 수도 있고, 심지어는 어댑터를 사용할 수도 있습니다.필요할 때만 건축 규범에 매우 유용하다.예컨대

tasks:
  build:
    cmds:
      - go build .
    sources:
      - ./*.go

source 개의 파일이 업데이트된 경우에만 실행됩니다go build.그러나 우리의 목적 때문에 우리는 파일을 입력하지 않았다.반대로 우리는 .go 필드를 사용하여 프로그래밍 검사를 할 수 있다.

  download-weather:
    desc: Downloads a weather forecast into a file
    cmds:
      - curl -s wttr.in?format=j1 > {{.WEATHER_FILE}}
    status:
      - test -f ./{{.WEATHER_FILE}}

여러 번 실행status하면 파일이 처음 다운로드되지만 나중에 다운로드되지는 않습니다.반대로 메시지가 생성됩니다: task download-weather.
이전의 task: Task "download-weather" is up to date 작업은 다운로드 중인 날씨 파일에 달려 있다.이것은 weather 필드를 통해 쉽게 완성할 수 있다.이것은 실행 명령deps이 실행을 시도한다는 것을 의미한다weather.다운로드 날씨는 반대로 날씨를 한 파일에 다운로드하지만, 이 파일이 아직 나타나지 않았을 때만...이것은 듣기에 매우 재미있지만, 내 말을 참을성 있게 들어 주십시오. 당신이 그 중의 가치를 볼 수 있기를 바랍니다.

  weather:
    desc: Prints out the current weather.
    deps:
      - download-weather
    cmds:
      - echo "There be $(cat {{.WEATHER_FILE}} | jq -r .current_condition[0].weatherDesc[0].value)"
    silent: true

날씨가 다운로드를 허용하면 download-weather를 실행하면 다음과 같은 출력이 발생합니다.

task: curl -s wttr.in?format=j1 > weather.json
There be Haze

그러나 다시 실행하면 다운로드되지 않으며 날씨 값만 인쇄할 수 있습니다.

task: Task "download-weather" is up to date
There be Haze

우리는 지금 그것의 가치를 볼 수 있기를 바란다.우리는 필요할 때만 일을 하는데, 모든 임무는 그것이 해야 할 일이 있는지 쉽게 검사할 수 있다.이것은 소프트웨어 개발에 매우 유용하다.예를 들어 우리는 task weather 임무에 의존하는 deploy 임무를 만들 수 있다.build 작업은 지난번build 이후 코드가 업데이트된 상황에서만 생성됩니다.우리는 심지어 build 생성된 파일이 지난번 배치보다 새로운 상황에서만 실제 배치를 실행할 수 있다.

하나의 진실한 예
지금까지 우리는 일기예보를 다운로드하기 위해 상당히 가식적인 예를 보았다.반대로 자바스크립트 프로젝트를 구축하는 흔한 코드 예시를 살펴보자.필요한 행동을 다음과 같이 정의할 수 있습니다.

운행deploy은 운행curl해야 한다.

task build 마지막 생성 이후 원본 파일에 새로운 변경 사항이 있을 때만 실행해야 합니다.

npm run build는 최신 버전npm run build이 설치된 경우에만 실행되어야 합니다.

최신 버전npm run build은 마지막 설치 후 패키지가 변경된 경우에만 설치할 수 있습니다.

이 세 가지 상황은 매직node_modules과 node_modules 도구를 사용하여 검사할 수 있다.test는 명령의 출력이 일부 내용을 되돌려주는지 확인하는 데 사용할 수 있다find.그것 또한 test를 사용하여 파일이 존재하는지 확인하고 test -z를 사용하여 디렉터리가 존재하는지 검사할 수 있다.파일/디렉터리가 존재하지 않거나 명령이 출력을 되돌려 주면 프로세스가 종료되고 상태 코드가 표시되어 명령이 실패했습니다.마지막으로test -ftest -d 출력보다 업데이트된 파일을 찾기 위해 표시합니다.
우리의 임무 서류.yml은 다음과 같습니다.

# https://taskfile.dev
version: '3'
output: prefixed
tasks:
  build:
    desc: Build all static artifacts into build
    deps: [ node_modules ]
    cmds:
      - npm run build
    status:
      # Lets check that our output directory exists
      - test -d build
      # And that our index.html file exists
      - test -f build/index.html
      # Finally, check if there are any files in `src`, `public` or `node_modules` that are newer than
      # out build/index.html output.
      - test -z "$(find src public node_modules -type f -newer build/index.html)"
  node_modules:
    desc: Install all dependencies
    cmds:
      - npm ci
    status:
      # Lets check that node_modules exists
      - test -d node_modules
      # Finally, we are up to date if any files in node_modules are newer than package.json
      - test -n "$(find node_modules/ -type f -newer package.json)"

마지막으로 테스트를 해 봅시다.첫 번째 실행find에서는 다음을 수행합니다.

$ task build
task: npm ci
> [email protected] postinstall ...
...
task: npm run build
> [email protected] build ...
...

그러나 두 번째 실행 시 다음과 같은 상황이 발생합니다.

$ task build
task: Task "node_modules" is up to date
task: Task "build" is up to date

-newer에 대한 변경 사항은 의존 항목을 다시 설치한 다음 다시 실행하여 생성합니다.task build 파일에 대한 변경 사항은 구축을 다시 실행합니다.이것은 구축이 한 번 또 한 번 운행하기 때문에 많은 시간을 절약할 수 있다.

결론
이 짧은 지침을 통해 우리는 매우 똑똑하지만 읽기 쉽고 이해하기 쉬운 임무집을 세웠다.이런 임무들은 스스로 기록할 수 있어 읽기와 이해에 편리하다.또한 package.json 및 src/ 필드를 사용하여 필요할 때만 작업을 수행할 수 있습니다.우리는 status 필드를 통해 이 임무들을 함께 연결할 수 있다.이런 방식으로 임무를 연결하면 이전의 어려운 임무를 쉽게 최적화할 수 있다. 방법은 그것을 구성 요소 부분으로 분해하고 실행할 필요가 없는 부분을 건너뛰는 것이다.우리는 두 가지 다른 예를 통해 이 점을 보았다. 한 사람의 인위적인 날씨 다운로드 프로그램과 더욱 전형적인 npm 프로젝트이다.이러한 예를 통해 우리는 sources가 제공할 수 있는 기능과 편의를 강조했다.누구나 쉽게 사용할 수 있다. 왜 우리가 사마제에서 그것을 좋아하는지 이해하길 바란다.