인스틸아이 소개

Instill의 파이프라인 백엔드 프로젝트 작업은 마치 퍼즐을 푸는 것과 같았습니다. 퍼즐—일부 조각의 이름이 계속 바뀌는 것을 제외하고! 내 임무는? 충돌을 일으키지 않고 JSON 필드의 이름을 바꿀 수 있는 구성 요소를 생성합니다. Go를 배우고, Instill의 잘 구성된 문서를 연구하고, 이제 병합되어 실행 준비가 된 솔루션을 만드는 과정을 공유하는 과정에 함께 해주세요! ?

도전

Instill에는 JSON 데이터 구조의 필드 이름을 동적으로 바꾸는 방법이 필요했습니다. 트위스트? 이름이 변경된 필드가 기존 필드와 충돌할 수 있는 경우를 처리해야 했습니다. 갈등 해결 시스템이 없으면 혼란이 최고조에 달할 것입니다!

flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e

flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e

솔직히 이 문제를 해결할 수 있을지 의문이 들기 시작했는데, 애니가 저를 계속 움직이게 하는 완벽한 메시지를 떨어뜨렸습니다.

내가 익숙해지자 이 작업을 위해 JSON 스키마를 만든 천하오가 나에게 승인을 줬다고? 코딩을 시작합니다. 그리하여 여행이 시작되었습니다!

2️⃣단계: 솔루션 설계

주요 요구 사항은 다음과 같습니다.

1. 동적 이름 바꾸기: JSON 구조를 방해하지 않고 필드 이름을 바꿔야 합니다.
2. 충돌 감지: 원래 필드와 이름이 바뀐 필드 사이의 충돌을 발견해야 했습니다.
3. 충돌 해결: 접미사 추가와 같은 원활한 해결을 통해 이름 충돌을 방지할 수 있습니다.

3️⃣ 단계: 구성요소 구축

커피 한잔과 용기?로 무장하고 코딩에 들어갔습니다. 핵심 논리를 살짝 엿보면 다음과 같습니다.

필드 매핑

먼저 이전 필드 이름과 새 필드 이름을 추적하는 매핑 시스템을 만들었습니다. 이것이 충돌을 감지하는 데 핵심이었습니다.

flowchart LR
s[Trigger] --> c1[OpenAI Component]
c1 --> c2[Stability AI Component]
c1 --> c3[MySQL Component]
c1 --> e[Response]
c2 --> e

충돌이 감지될 때마다 함수는 새 이름에 "_contribute"를 추가했습니다. 이는 JSON 필드를 고유하게 유지하고 가장 중요하게는 서로 친숙하게 유지하는 간단한 방법입니다! ✌️

필드 이름 바꾸기

필드 매핑이 완료되면 다음 단계는 이를 JSON 데이터에 적용하는 것이었습니다.

variable
  <span># pipeline input fields</span>
output:
  <span># pipeline output fields</span>
component:
  <component-id>:
    type: <component-definition-id>
    task: <task-id>
    input:
      <span># values for the input fields</span>
    condition: <condition> <span># conditional statement to execute or bypass the</span>

매핑된 이름을 JSON 데이터에 적용하는 논리는 다음과 같습니다. 결과는? 데이터의 이름이 깔끔하게 변경되고, 충돌이 해결되었으며, 구조가 그대로 유지되었습니다. ?

구성 요소를 만든 후 PR 초안을 삭제하고 댓글을 받았습니다.

4️⃣단계: 테스트 및 개선

Instill의 테스트 방법을 익히고 효과적인 테스트 케이스를 만드는 방법을 배운 후 더 진행했습니다.

테스트 시간! ? 간단한 이름 바꾸기부터 중첩된 JSON 필드가 있는 복잡한 엣지 케이스까지 모든 것을 다루는 테스트를 작성했습니다. 각 테스트를 통해 더욱 개선되었습니다.

func mapFields(fields map[string]string) map[string]string {
    newFieldMap := make(map[string]string)
    for oldName, newName := range fields {
        // Check for conflict
        if _, exists := newFieldMap[newName]; exists {
            newName += "_conflict" // Add suffix for conflicts
        }
        newFieldMap[oldName] = newName
    }
    return newFieldMap
}

여기에서 개인적인 생각을 공유하고 싶습니다. 테스트는 이 프로젝트에서 가장 어려운 부분 ?‍?입니다. '이 테스트가 원래대로 되는 걸까?'라고 생각한 적도 있었습니다.

그때 린트 문제가 발생했습니다.—

문제를 지적하고 해결책까지 제시해주셨어요. 구현만 하면 되지만, 코드가 원활하게 작동하려면 아주 작은 디테일도 중요하다는 점을 상기시켜준 것입니다.

초기 장애물을 극복한 후에는 테스트가 안전망이 되었습니다. 내 코드가 다양한 시나리오에서 작동할 것이라는 확신을 얻었습니다 ?️‍♂️. 또한 테스트는 단지 확인하는 단계가 아니라 내 코드의 신뢰성과 복원력을 확인하는 방법이라는 사실도 보여주었습니다.

5️⃣ 단계: CI 확인 및 최종 조정

테스트를 완료한 후 코드를 푸시하여 검토 프로세스를 준비했습니다. 그러나 CI(지속적 통합) 검사를 통과하지 못했습니다. Anni의 댓글은 내 테스트 사례를 다시 확인하라는 점을 부드럽게 상기시켜주었습니다.

“@AkashJana18님, 테스트 케이스를 확인해 주시겠어요? CI 확인 결과 여기에서는 통과되지 않은 것으로 나타났습니다. PR에 푸시하기 전에 먼저 로컬에서 테스트해 보세요. 커밋을 푸시할 때마다 엔지니어가 코드를 검토하기 전에 문제를 발견할 수 있도록 검사가 시작됩니다. 감사합니다!”

그때 제출하기 전에 로컬에서 테스트를 실행해야 한다는 것을 깨달았습니다. 춘하오님도 추가했습니다:

"검토를 요청하기 전에 실행하고 통과하세요. 로컬에서 확인하려면 $ go test ./pkg/comComponent/operator/json/v0/...를 실행하세요."

현지에서 신속하게 테스트를 실행하고 문제를 파악하여 해결했습니다.

잠깐의 축하의 순간 ?

이 과정을 통해 검토를 위해 제출하기 전에 모든 것이 확실하게 확인되었으므로 로컬 테스트의 중요성을 더욱 인식하게 되었습니다.

병합하기 전에 ChunHao는 최종 검토를 수행하고 몇 가지 수정 사항과 QAed 테스트 레시피를 수행하고 새로운 변경 사항을 반영하도록 문서를 업데이트했습니다. 프로세스 전반에 걸쳐 지속적인 지원을 제공한 Anni에게 큰 감사를 드립니다. 이는 큰 변화를 가져왔습니다. ?

? 협업 프로세스에 대한 성찰 ??‍??

제가 배운 가장 큰 교훈 중 하나는 협업과 멘토링이 어떻게 프로젝트를 성패시킬 수 있는지는 것이었습니다. Instill의 중재자인 Anni와 ChunHao는 제가 Go 구문에 대해 헤매거나 올바른 접근 방식을 찾는 데 어려움을 겪을 때 필요한 지침을 제공했습니다. 우리는 함께 협력하여 복잡한 문제를 깔끔하고 기능적인 솔루션으로 전환했습니다.

솔직히 씹을 수 없을 만큼 물어뜯은 것 같은 순간도 있었습니다. 하지만 애니의 끊임없는 격려와 춘하오의 명확한 방향이 저를 계속해서 순조롭게 이끌어주었습니다.

⏭️ 다음 단계 및 향후 개선 사항

또 다른 단계는 이 접근 방식을 동적 필드 이름 처리가 필요한 파이프라인의 다른 부분으로 확장하는 것입니다. 약간의 자동화를 좋아하지 않는 사람이 있을까요⚙️?

?️ 도구 및 리소스 ?

1. Go 문서: Go 구문을 자세히 살펴보고 핵심 개념을 이해합니다.
2. Instill Docs: Instill 파이프라인을 이해하기 위한 잘 정리된 리소스의 금광입니다.
3. Go 테스트 프레임워크: 단위 테스트를 작성하고 모든 것이 예상대로 작동하는지 확인하며 CI 도구와 통합하기 위해 Go에 내장된 테스트 패키지입니다.
4. Golangci-lint: A Go 린터 수집기는 개발 및 CI 검사 중에 문제를 식별하고 코드 품질을 강화합니다.

??‍??️ 나의 학습

Instill의 견고한 문서화, ChunHao의 지도, Anni의 도덕적 지원 덕분에 이 프로젝트는 환상적인 학습 경험이 되었습니다. 저는 Go에 대해 아무것도 모르는 상태에서 생산 준비가 완료된 완전한 기능의 기능을 구현하게 되었습니다(그리고 이를 증명하기 위해 병합된 PR이 있습니까?).

증거:

위 내용은 0에서 병합까지: Go에서 JSON 이름 변경 필드 구성 요소 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!