From 524d8ee942e418b9beb4fb35947e5915230cb7cc Mon Sep 17 00:00:00 2001 From: Me1e Date: Sat, 15 Apr 2023 02:29:20 +0900 Subject: [PATCH] =?UTF-8?q?Rename=20the=20word=20"=EC=9B=8C=ED=81=AC?= =?UTF-8?q?=ED=94=8C=EB=A1=9C=EC=9A=B0"=20to=20"Workflow"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 2022/ko/Days/day04.md | 2 +- 2022/ko/Days/day07.md | 2 +- 2022/ko/Days/day24.md | 2 +- 2022/ko/Days/day31.md | 2 +- 2022/ko/Days/day33.md | 2 +- 2022/ko/Days/day37.md | 2 +- 2022/ko/Days/day38.md | 2 +- 2022/ko/Days/day39.md | 2 +- 2022/ko/Days/day40.md | 2 +- 2022/ko/Days/day41.md | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-) diff --git a/2022/ko/Days/day04.md b/2022/ko/Days/day04.md index 36b2a88..8fdae78 100644 --- a/2022/ko/Days/day04.md +++ b/2022/ko/Days/day04.md @@ -82,7 +82,7 @@ id: 1048700 1. 개발 팀과 운영 팀을 통합합니다. 2. 빌드 및 운영 팀을 만들고 모든 개발 및 운영 관련 문제를 전체 DevOps 팀에서 논의합니다. -3. 스프린트에 대한 접근 방식을 변경하고 우선순위를 지정하여 개발 작업과 동일한 가치를 지닌 DevOps 작업을 제공하세요. 개발 팀과 운영 팀이 다른 팀의 워크플로와 발생 가능한 문제에 대해 의견을 교환하도록 장려하세요. +3. 스프린트에 대한 접근 방식을 변경하고 우선순위를 지정하여 개발 작업과 동일한 가치를 지닌 DevOps 작업을 제공하세요. 개발 팀과 운영 팀이 다른 팀의 workflow와 발생 가능한 문제에 대해 의견을 교환하도록 장려하세요. 4. 모든 개발 단계에 QA를 포함하세요. 5. 올바른 도구를 선택하세요. 6. 가능한 모든 것을 자동화하세요. diff --git a/2022/ko/Days/day07.md b/2022/ko/Days/day07.md index e52679c..b901e8d 100644 --- a/2022/ko/Days/day07.md +++ b/2022/ko/Days/day07.md @@ -28,7 +28,7 @@ Kasten K10이나 Terraform, HCL과 같은 데브옵스 도구와 상호 작용 ## 제가 방금 프로그래밍 언어를 배우지 말라고 설득한 건가요? -많은 경우, 데브옵스 엔지니어의 주된 책임은 엔지니어링 팀과 협력하여 데브옵스 관행을 워크플로우에 통합하는 것입니다. 여기에는 애플리케이션에 대한 광범위한 테스트와 워크플로우가 앞서 설명한 데브옵스 원칙을 준수하는지 확인하는 작업인 경우가 많습니다. 그러나 작업의 상당 부분에는 애플리케이션 성능 또는 기타 기술적 결함과 관련된 문제 해결도 포함될 수 있습니다. 따라서 작업 중인 애플리케이션에서 사용하는 프로그래밍 언어에 대한 전문 지식을 갖추는 것이 중요합니다. 예를 들어, 애플리케이션이 Node.js로 작성된 경우 Go나 Python을 알아도 별 도움이 되지 않습니다. +많은 경우, 데브옵스 엔지니어의 주된 책임은 엔지니어링 팀과 협력하여 데브옵스 관행을 workflow에 통합하는 것입니다. 여기에는 애플리케이션에 대한 광범위한 테스트와 workflow가 앞서 설명한 데브옵스 원칙을 준수하는지 확인하는 작업인 경우가 많습니다. 그러나 작업의 상당 부분에는 애플리케이션 성능 또는 기타 기술적 결함과 관련된 문제 해결도 포함될 수 있습니다. 따라서 작업 중인 애플리케이션에서 사용하는 프로그래밍 언어에 대한 전문 지식을 갖추는 것이 중요합니다. 예를 들어, 애플리케이션이 Node.js로 작성된 경우 Go나 Python을 알아도 별 도움이 되지 않습니다. ## 왜 Go인가요? diff --git a/2022/ko/Days/day24.md b/2022/ko/Days/day24.md index 7823780..094a6dc 100644 --- a/2022/ko/Days/day24.md +++ b/2022/ko/Days/day24.md @@ -34,7 +34,7 @@ id: 1048805 작업을 식별하고 네트워크 변경 요청에 대한 검색을 수행하여 솔루션을 자동화할 가장 일반적인 이슈와 문제를 파악해야 합니다. -- 현재 수동으로 처리하고 있는 모든 변경 요청과 워크플로우의 목록을 작성합니다. +- 현재 수동으로 처리하고 있는 모든 변경 요청과 workflow의 목록을 작성합니다. - 가장 일반적이고 시간이 오래 걸리며 오류가 발생하기 쉬운 활동을 파악하세요. - 비즈니스 중심 접근 방식을 취하여 요청의 우선순위를 정하세요. - 이는 자동화 프로세스를 구축하기 위한 프레임워크이며, 자동화해야 하는 작업과 자동화하지 않아야 하는 작업을 구분합니다. diff --git a/2022/ko/Days/day31.md b/2022/ko/Days/day31.md index f0cf7e2..f7b1e1b 100644 --- a/2022/ko/Days/day31.md +++ b/2022/ko/Days/day31.md @@ -100,7 +100,7 @@ Azure Functions - 서버리스 코드를 제공합니다. 퍼블릭 클라우드 Azure Event Grid를 사용하면 서비스 및 이벤트에서 로직을 트리거할 수 있습니다. -Azure Logic App은 그래픽 기반 워크플로 및 통합을 제공합니다. +Azure Logic App은 그래픽 기반 workflow 및 통합을 제공합니다. 또한 일관된 관리 및 예약을 통해 Windows 및 Linux 노드 모두에서 대규모 작업을 실행할 수 있는 Azure Batch도 살펴볼 수 있습니다. diff --git a/2022/ko/Days/day33.md b/2022/ko/Days/day33.md index 1d702eb..6be0712 100644 --- a/2022/ko/Days/day33.md +++ b/2022/ko/Days/day33.md @@ -88,7 +88,7 @@ Microsoft Azure에는 두 가지 로드 밸런싱 솔루션이 있습니다. ( ### Azure 포털 -Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 워크플로우에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다. +Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 workflow에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다. ![](/2022/Days/Images/Day33_Cloud2.png) diff --git a/2022/ko/Days/day37.md b/2022/ko/Days/day37.md index cc069f8..c5965f6 100644 --- a/2022/ko/Days/day37.md +++ b/2022/ko/Days/day37.md @@ -12,7 +12,7 @@ id: 1048707 제목과 글 전체에 끔찍한 말장난이 들어가서 죄송합니다. Git을 아재 개그로 바꾼 사람이 제가 처음은 아닐 겁니다! -지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 워크플로우에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다. +지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 workflow에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다. 이제 Git에서 흔히 볼 수 있는 몇 가지 명령어와 사용 사례를 살펴보겠습니다. diff --git a/2022/ko/Days/day38.md b/2022/ko/Days/day38.md index 1e63b6a..a1a8289 100644 --- a/2022/ko/Days/day38.md +++ b/2022/ko/Days/day38.md @@ -70,7 +70,7 @@ Nano가 열리면 설명을 추가한 다음 파일을 저장할 수 있습니 프로젝트에서 파일을 제거하는 것은 어떨까요? 디렉토리에 커밋했지만 이제 프로젝트에 더 이상 필요하지 않거나 사용하지 않는 다른 파일이 있는 경우, 파일을 제거해야 합니다. -디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 워크플로우를 확인할 수 있습니다. +디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 workflow를 확인할 수 있습니다. ![](/2022/Days/Images/Day38_Git9.png) diff --git a/2022/ko/Days/day39.md b/2022/ko/Days/day39.md index 116e7f0..8f8234d 100644 --- a/2022/ko/Days/day39.md +++ b/2022/ko/Days/day39.md @@ -196,7 +196,7 @@ git rebase main rebase의 가장 큰 장점은 프로젝트 히스토리가 훨씬 깔끔해진다는 것입니다. 또한 불필요한 merge commit을 제거하며, 마지막 두 이미지를 비교하면 훨씬 더 깔끔한 선형 프로젝트 히스토리를 따라갈 수 있습니다. -아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 워크플로에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다. +아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 workflow에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다. ## 자료 diff --git a/2022/ko/Days/day40.md b/2022/ko/Days/day40.md index ccb0738..d031db5 100644 --- a/2022/ko/Days/day40.md +++ b/2022/ko/Days/day40.md @@ -185,7 +185,7 @@ Insight 탭은 리포지토리의 활동량부터 commit 및 issues에 이르기 이 단계에서는 이 작업이 완료되고 우리만 새로운 변경 사항을 사용할 것이므로 변경 사항에 만족할 수도 있지만, 버그 변경일 수도 있으며 이 경우, pull requests를 통해 기여하여 원래 리포지토리 관리자에게 변경 사항을 알리고 변경 사항을 수락하는지 확인하고 싶을 것입니다. -아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 워크플로우를 살펴보면서 이에 대해 더 자세히 다루겠습니다. +아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 workflow를 살펴보면서 이에 대해 더 자세히 다루겠습니다. ![](/2022/Days/Images/Day40_Git29.png) diff --git a/2022/ko/Days/day41.md b/2022/ko/Days/day41.md index 739c195..bdcba09 100644 --- a/2022/ko/Days/day41.md +++ b/2022/ko/Days/day41.md @@ -8,7 +8,7 @@ canonical_url: null id: 1048806 --- -## 오픈 소스 워크플로 +## 오픈 소스 workflow 지난 7회에 걸친 Git 섹션을 통해 Git이 무엇인지, 그리고 GitHub와 같은 Git 기반 서비스가 어떻게 소스 코드 저장소를 제공할 뿐만 아니라 더 많은 커뮤니티가 함께 코드와 프로젝트를 협업할 수 있는 방법을 제공하는지 더 잘 이해하셨기를 바랍니다.