गो वर्कस्पेस संरचना: गोपाथ से go.work तक

आधुनिक वर्कस्पेस के साथ गो प्रोजेक्ट्स को कुशलतापूर्वक संगठित करें

Page content

गो प्रोजेक्ट्स को प्रभावी ढंग से प्रबंधित करना कोड, डिपेंडेंसीज, और बिल्ड एन्वायर्नमेंट्स को कैसे संगठित करते हैं, इसके बारे में समझने की आवश्यकता होती है।

गो का दृष्टिकोण महत्वपूर्ण रूप से विकसित हुआ है—रिगिड GOPATH सिस्टम से फ्लेक्सिबल मॉड्यूल-आधारित वर्कफ्लो तक, और अंत में Go 1.18 के वर्कस्पेस फीचर तक, जो मल्टी-मॉड्यूल डेवलपमेंट को सुव्यवस्थित ढंग से संभालता है।

गोफर का कार्यस्थल

गो वर्कस्पेस विकास का समझना

गो के वर्कस्पेस मॉडल ने तीन अलग-अलग युगों से गुजरा, हर एक अपने पूर्ववर्ती की सीमाओं को दूर करता हुआ, जबकि पीछे की संगतता बनाए रखता है।

द गोपाथ युग (प्री-गो 1.11)

शुरू में, गो ने एक कड़ी वर्कस्पेस संरचना लागू की थी जो GOPATH एन्वायर्नमेंट वेरिएबल के आसपास केंद्रित थी:

$GOPATH/
├── src/
│   ├── github.com/
│   │   └── username/
│   │       └── project1/
│   ├── gitlab.com/
│   │   └── company/
│   │       └── project2/
│   └── ...
├── bin/      # कम्पाइल किए गए एक्सीक्यूटेबल्स
└── pkg/      # कम्पाइल किए गए पैकेज ऑब्जेक्ट्स

सभी गो कोड को $GOPATH/src के भीतर रहना पड़ता था, जो इम्पोर्ट पाथ द्वारा संगठित था। जबकि यह भविष्यवाणी की अनुमति देता था, यह महत्वपूर्ण घर्षण पैदा करता था:

  • नो वर्जनिंग: आप एक समय में एक ही डिपेंडेंसी का केवल एक वर्जन रख सकते थे
  • ग्लोबल वर्कस्पेस: सभी प्रोजेक्ट्स डिपेंडेंसीज साझा करते थे, जिससे संघर्ष होते थे
  • रिगिड स्ट्रक्चर: प्रोजेक्ट्स GOPATH के बाहर नहीं रह सकते थे
  • वेंडर हेल: अलग-अलग वर्जन प्रबंधित करने के लिए जटिल वेंडर डायरेक्टरी की आवश्यकता होती थी

द गो मॉड्यूल्स युग (गो 1.11+)

गो मॉड्यूल्स ने प्रोजेक्ट प्रबंधन को क्रांतिकारी बनाया go.mod और go.sum फाइलों को पेश करके:

myproject/
├── go.mod          # मॉड्यूल डिफिनिशन और डिपेंडेंसीज
├── go.sum          # क्रिप्टोग्राफिक चेकसम्स
├── main.go
└── internal/
    └── service/

मुख्य लाभ:

  • प्रोजेक्ट्स आपकी फाइल सिस्टम के किसी भी स्थान पर रह सकते हैं
  • हर प्रोजेक्ट अपने डिपेंडेंसीज को स्पष्ट वर्जन के साथ प्रबंधित करता है
  • चेकसम्स के माध्यम से पुनरुत्पादित बिल्ड
  • सेमांटिक वर्जनिंग सपोर्ट (v1.2.3)
  • लोकल डेवलपमेंट के लिए रिप्लेस डायरेक्टिव्स

एक मॉड्यूल को इनिशियलाइज़ करें:

go mod init github.com/username/myproject

गो कमांड्स और मॉड्यूल प्रबंधन के लिए एक व्यापक संदर्भ के लिए, गो चीटशीट देखें।

गोपाथ और गो वर्कस्पेस के बीच अंतर क्या है?

मूलभूत अंतर स्कोप और फ्लेक्सिबिलिटी में है। GOPATH एक एकल, ग्लोबल वर्कस्पेस था जिसमें सभी कोड को एक विशेष डायरेक्टरी संरचना में रहना पड़ता था। इसमें वर्जनिंग की कोई अवधारणा नहीं थी, जिससे डिपेंडेंसी संघर्ष होते थे जब अलग-अलग प्रोजेक्ट्स एक ही पैकेज के अलग-अलग वर्जन चाहते थे।

आधुनिक गो वर्कस्पेस, जो गो 1.18 में go.work फाइल के साथ पेश किए गए थे, लोकल, प्रोजेक्ट-स्पेसिफिक वर्कस्पेस प्रदान करते हैं जो कई मॉड्यूल्स को एक साथ प्रबंधित करते हैं। हर मॉड्यूल अपने go.mod फाइल के साथ स्पष्ट वर्जनिंग बनाए रखता है, जबकि go.work उन्हें लोकल डेवलपमेंट के लिए समन्वयित करता है। यह आपको करने की अनुमति देता है:

  • एक लाइब्रेरी और उसके उपभोक्ता को साथ-साथ विकसित करें
  • इंटरडिपेंडेंट मॉड्यूल्स को प्रकाशित किए बिना विकसित करें
  • मॉड्यूल्स के बीच परिवर्तनों को कमिट करने से पहले परीक्षण करें
  • हर मॉड्यूल को स्वतंत्र रूप से वर्जन और डिप्लॉय किया जा सके

सबसे महत्वपूर्ण बात, वर्कस्पेस ऑप्ट-इन डेवलपमेंट टूल्स हैं—आपके मॉड्यूल्स बिना उन्हें भी अच्छी तरह से काम करते हैं, जबकि GOPATH अनिवार्य था।

आधुनिक वर्कस्पेस: go.work फाइलों

गो 1.18 ने एक सामान्य समस्या को हल करने के लिए वर्कस्पेस पेश किए: आप स्थानीय रूप से कई संबंधित मॉड्यूल्स विकसित कैसे करते हैं बिना कि आप लगातार परिवर्तनों को पुश और पुल करते हैं?

मुझे go.work फाइल के बजाय go.mod का उपयोग कब करना चाहिए?

go.work का उपयोग तब करें जब आप कई मॉड्यूल्स को सक्रिय रूप से विकसित कर रहे हों जो एक दूसरे पर निर्भर करते हैं। सामान्य स्थितियाँ शामिल हैं:

मोनोरिपो डेवलपमेंट: एक ही रिपोजिटरी में कई सेवाएँ जो एक दूसरे को रेफरेंस करती हैं।

लाइब्रेरी डेवलपमेंट: आप एक लाइब्रेरी बना रहे हैं और इसे प्रकाशित किए बिना एक उपभोक्ता एप्लिकेशन में परीक्षण करना चाहते हैं।

माइक्रोसर्विसेज: कई सेवाएँ सामान्य आंतरिक पैकेज साझा करती हैं जिन्हें आप संशोधित कर रहे हैं।

ओपन सोर्स योगदान: आप एक डिपेंडेंसी पर काम कर रहे हैं और अपने एप्लिकेशन में साथ-साथ परिवर्तनों का परीक्षण कर रहे हैं।

go.work का उपयोग न करें:

  • सिंगल-मॉड्यूल प्रोजेक्ट्स के लिए (बस go.mod का उपयोग करें)
  • प्रोडक्शन बिल्ड्स के लिए (वर्कस्पेस केवल डेवलपमेंट के लिए हैं)
  • प्रोजेक्ट्स के लिए जहां सभी डिपेंडेंसीज बाहरी और स्थिर हैं

वर्कस्पेस बनाना और प्रबंधित करना

एक वर्कस्पेस इनिशियलाइज़ करें:

cd ~/projects/myworkspace
go work init

यह एक खाली go.work फाइल बनाता है। अब मॉड्यूल्स जोड़ें:

go work use ./api
go work use ./shared
go work use ./worker

या वर्तमान डायरेक्टरी में सभी मॉड्यूल्स को रिकर्सिव रूप से जोड़ें:

go work use -r .

निर्मित go.work फाइल:

go 1.21

use (
    ./api
    ./shared
    ./worker
)

वर्कस्पेस कैसे काम करता है

जब एक go.work फाइल मौजूद होती है, तो गो टूलचेन इसे डिपेंडेंसीज को रिज़ॉल्व करने के लिए उपयोग करता है। अगर मॉड्यूल api shared को इम्पोर्ट करता है, तो गो पहले वर्कस्पेस में देखता है पहले कि बाहरी रिपोजिटरीज की जांच करे।

उदाहरण वर्कस्पेस संरचना:

myworkspace/
├── go.work
├── api/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── shared/
│   ├── go.mod
│   └── auth/
│       └── auth.go
└── worker/
    ├── go.mod
    └── main.go

api/main.go में, आप shared/auth को सीधे इम्पोर्ट कर सकते हैं:

package main

import (
    "fmt"
    "myworkspace/shared/auth"
)

func main() {
    token := auth.GenerateToken()
    fmt.Println(token)
}

shared/auth में परिवर्तन api के लिए तुरंत दृश्यमान होते हैं बिना प्रकाशित या वर्जन अपडेट किए।

क्या मुझे go.work फाइलों को वर्जन कंट्रोल में कमिट करना चाहिए?

नहीं—कतई नहीं। go.work फाइल एक लोकल डेवलपमेंट टूल है, एक प्रोजेक्ट आर्टिफैक्ट नहीं। यहाँ कारण हैं:

पाथ स्पेसिफिसिटी: आपकी go.work लोकल फाइल पाथ्स को रेफरेंस करती है जो अन्य मशीनों या CI/CD सिस्टम पर मौजूद नहीं होंगे।

बिल्ड रिप्रोड्यूसिबिलिटी: प्रोडक्शन बिल्ड्स को go.mod का उपयोग करके सुनिश्चित करना चाहिए ताकि स्थिर डिपेंडेंसी रिज़ॉल्विंग हो।

डेवलपर फ्लेक्सिबिलिटी: हर डेवलपर अपने लोकल वर्कस्पेस को अलग तरह से संगठित कर सकता है।

CI/CD असंगतता: स्वचालित बिल्ड सिस्टम केवल go.mod फाइलों की अपेक्षा करते हैं।

हमेशा go.work और go.work.sum को .gitignore में जोड़ें:

# .gitignore
go.work
go.work.sum

आपका CI/CD पाइपलाइन और अन्य डेवलपर हर मॉड्यूल के go.mod फाइल का उपयोग करके बिल्ड करेंगे, जिससे सभी एन्वायर्नमेंट्स में पुनरुत्पादित बिल्ड सुनिश्चित होंगे।

व्यावहारिक वर्कस्पेस पैटर्न

पैटर्न 1: मोनोरिपो के साथ कई सेवाएँ

company-platform/
├── go.work
├── cmd/
│   ├── api/
│   │   ├── go.mod
│   │   └── main.go
│   ├── worker/
│   │   ├── go.mod
│   │   └── main.go
│   └── scheduler/
│       ├── go.mod
│       └── main.go
├── internal/
│   ├── auth/
│   │   ├── go.mod
│   │   └── auth.go
│   └── database/
│       ├── go.mod
│       └── db.go
└── pkg/
    └── logger/
        ├── go.mod
        └── logger.go

मल्टी-टेनेंट एप्लिकेशन्स के लिए डेटाबेस आइसोलेशन की आवश्यकता होती है, तो गो में मल्टी-टेनेंसी डेटाबेस पैटर्न्स के साथ उदाहरण का पता लगाने का विचार करें।

हर घटक एक स्वतंत्र मॉड्यूल है जिसका अपना go.mod है। वर्कस्पेस उन्हें समन्वयित करता है:

go 1.21

use (
    ./cmd/api
    ./cmd/worker
    ./cmd/scheduler
    ./internal/auth
    ./internal/database
    ./pkg/logger
)

मोनोरिपो सेटअप में API सेवाओं को बिल्ड करते समय, अपने एंडपॉइंट्स को उचित रूप से दस्तावेज़ीकरण करना आवश्यक है। अपने गो API में स्वैगर जोड़ना के बारे में अधिक जानें।

पैटर्न 2: लाइब्रेरी और उपभोक्ता डेवलपमेंट

आप mylib विकसित कर रहे हैं और इसे myapp में परीक्षण करना चाहते हैं:

dev/
├── go.work
├── mylib/
│   ├── go.mod       # module github.com/me/mylib
│   └── lib.go
└── myapp/
    ├── go.mod       # module github.com/me/myapp
    └── main.go      # imports github.com/me/mylib

वर्कस्पेस फाइल:

go 1.21

use (
    ./mylib
    ./myapp
)

mylib में परिवर्तन myapp में तुरंत परीक्षण योग्य हैं बिना GitHub पर प्रकाशित किए।

पैटर्न 3: फोर्क डेवलपमेंट और परीक्षण

आपने एक बग को ठीक करने के लिए एक डिपेंडेंसी को फोर्क किया है:

projects/
├── go.work
├── myproject/
│   ├── go.mod       # uses github.com/upstream/lib
│   └── main.go
└── lib-fork/
    ├── go.mod       # module github.com/upstream/lib
    └── lib.go       # आपका बग फिक्स

वर्कस्पेस आपको अपने फोर्क का परीक्षण करने की अनुमति देता है:

go 1.21

use (
    ./myproject
    ./lib-fork
)

go कमांड github.com/upstream/lib को आपकी लोकल ./lib-fork डायरेक्टरी में रिज़ॉल्व करता है।

मैं अपने विकास मशीन पर कई गो प्रोजेक्ट्स को कैसे संगठित करूँ?

संगठन रणनीति आपकी विकास शैली और प्रोजेक्ट संबंधों पर निर्भर करती है।

रणनीति 1: फ्लैट प्रोजेक्ट संरचना

असंबंधित प्रोजेक्ट्स के लिए उन्हें अलग रखें:

~/dev/
├── personal-blog/
│   ├── go.mod
│   └── main.go
├── work-api/
│   ├── go.mod
│   └── cmd/
├── side-project/
│   ├── go.mod
│   └── server.go
└── experiments/
    └── ml-tool/
        ├── go.mod
        └── main.go

हर प्रोजेक्ट स्वतंत्र है। वर्कस्पेस की आवश्यकता नहीं है—हर एक अपने निर्भरताओं का प्रबंधन go.mod के माध्यम से करता है।

रणनीति 2: डोमेन-समूहित संगठन

संबंधित प्रोजेक्ट्स को डोमेन या उद्देश्य के अनुसार समूहित करें:

~/dev/
├── work/
│   ├── platform/
│   │   ├── go.work
│   │   ├── api/
│   │   ├── worker/
│   │   └── shared/
│   └── tools/
│       ├── deployment-cli/
│       └── monitoring-agent/
├── open-source/
│   ├── go-library/
│   └── cli-tool/
└── learning/
    ├── algorithms/
    └── design-patterns/

डोमेन जैसे platform/ के भीतर संबंधित प्रोजेक्ट्स के लिए वर्कस्पेस (go.work) का उपयोग करें, लेकिन असंबंधित प्रोजेक्ट्स को अलग रखें। यदि आप अपने वर्कस्पेस में CLI टूल्स बना रहे हैं, तो Building CLI Applications in Go with Cobra & Viper पढ़ने का विचार करें।

रणनीति 3: क्लाइंट या संगठन-आधारित

फ्रीलांसर या कंसल्टेंट जो कई क्लाइंट्स का प्रबंधन करते हैं:

~/projects/
├── client-a/
│   ├── ecommerce-platform/
│   └── admin-dashboard/
├── client-b/
│   ├── go.work
│   ├── backend/
│   ├── shared-types/
│   └── worker/
└── internal/
    ├── my-saas/
    └── tools/

जब क्लाइंट्स के प्रोजेक्ट्स परस्पर निर्भर होते हैं, तो हर क्लाइंट के लिए वर्कस्पेस बनाएँ।

संगठन सिद्धांत

नेस्टिंग गहराई को सीमित करें: 2-3 डायरेक्टरी स्तरों के भीतर रहें। गहरे हायरार्की अकुशल हो जाते हैं।

सार्थक नामों का उपयोग करें: ~/dev/platform/ ~/p1/ से अधिक स्पष्ट है।

चिंताओं को अलग करें: काम, व्यक्तिगत, प्रयोग और ओपन-सोर्स योगदानों को अलग रखें।

संरचना का दस्तावेजीकरण करें: अपने रूट विकास फोल्डर में एक README.md जोड़ें जिसमें संगठन का वर्णन हो।

संगत कन्वेंशन्स: सभी प्रोजेक्ट्स के लिए एक ही संरचना पैटर्न का उपयोग करें ताकि मांसपेशियों की स्मृति हो।

गो वर्कस्पेस का उपयोग करते समय आम गलतियाँ क्या हैं?

गलती 1: go.work को Git में कमिट करना

जैसा कि पहले चर्चा की गई है, यह अन्य डेवलपर्स और CI/CD सिस्टम के लिए बिल्ड्स तोड़ देता है। हमेशा इसे gitignore करें।

गलती 2: सभी कमांडों से go.work का सम्मान करने की उम्मीद करना

सभी Go कमांड go.work का सम्मान नहीं करते। विशेष रूप से, go mod tidy व्यक्तिगत मॉड्यूल पर काम करता है, न कि वर्कस्पेस पर। जब आप एक मॉड्यूल के भीतर go mod tidy चलाते हैं, तो यह वर्कस्पेस में मौजूद निर्भरताओं को प्राप्त करने का प्रयास कर सकता है, जिससे भ्रम होता है।

हल: हर मॉड्यूल डायरेक्टरी के भीतर go mod tidy चलाएँ, या इस कमांड का उपयोग करें:

go work sync

यह कमांड go.work को अपडेट करता है ताकि मॉड्यूल्स के बीच संगति सुनिश्चित हो।

गलती 3: गलत रिप्लेस डायरेक्टिव्स

go.mod और go.work दोनों में replace डायरेक्टिव्स का उपयोग करना संघर्ष पैदा कर सकता है:

# go.work
use (
    ./api
    ./shared
)

replace github.com/external/lib => ../external-lib  # वर्कस्पेस के लिए सही

# api/go.mod
replace github.com/external/lib => ../../../somewhere-else  # संघर्ष!

हल: वर्कस्पेस का उपयोग करते समय क्रॉस-मॉड्यूल रिप्लेस के लिए replace डायरेक्टिव्स को go.work में रखें, न कि व्यक्तिगत go.mod फाइलों में।

गलती 4: वर्कस्पेस के बिना परीक्षण न करना

आपका कोड go.work के साथ स्थानीय रूप से काम कर सकता है लेकिन उत्पादन या CI में विफल हो सकता है जहां वर्कस्पेस मौजूद नहीं है।

हल: समय-समय पर वर्कस्पेस को निष्क्रिय करके बिल्ड्स का परीक्षण करें:

GOWORK=off go build ./...

यह सिमुलेट करता है कि आपका कोड उत्पादन में कैसे बिल्ड होता है।

गलती 5: GOPATH और मॉड्यूल मोड्स को मिलाना

कुछ डेवलपर्स पुराने प्रोजेक्ट्स को GOPATH में रखते हैं जबकि अन्य स्थानों पर मॉड्यूल का उपयोग करते हैं, जिससे यह भ्रम होता है कि कौन सा मोड सक्रिय है।

हल: पूर्ण रूप से मॉड्यूल्स में माइग्रेट करें। यदि आपको पुराने GOPATH प्रोजेक्ट्स को बनाए रखना है, तो Go संस्करण प्रबंधकों जैसे gvm या Docker कंटेनर्स का उपयोग करें ताकि वातावरण को अलग करें।

गलती 6: go.work.sum को भूल जाना

go.sum की तरह, वर्कस्पेस go.work.sum उत्पन्न करते हैं ताकि निर्भरताओं की पुष्टि की जा सके। इसे कमिट न करें, लेकिन इसे हटाने का प्रयास भी न करें—यह विकास के दौरान पुनरुत्पाद्य बिल्ड्स सुनिश्चित करता है।

गलती 7: अत्यधिक व्यापक वर्कस्पेस

असंबंधित मॉड्यूल्स को वर्कस्पेस में जोड़ना बिल्ड्स को धीमा करता है और जटिलता बढ़ाता है।

हल: वर्कस्पेस को निकटता से संबंधित मॉड्यूल्स पर केंद्रित रखें। यदि मॉड्यूल्स परस्पर क्रिया नहीं करते, तो उन्हें एक वर्कस्पेस साझा करने की आवश्यकता नहीं है।

उन्नत वर्कस्पेस तकनीकें

रिप्लेस डायरेक्टिव्स के साथ काम करना

go.work में replace डायरेक्टिव मॉड्यूल आयात को पुनर्निर्देशित करता है:

go 1.21

use (
    ./api
    ./shared
)

replace (
    github.com/external/lib v1.2.3 => github.com/me/lib-fork v1.2.4
    github.com/another/lib => ../local-another-lib
)

यह शक्तिशाली है:

  • फोर्क किए गए निर्भरताओं का परीक्षण
  • बाहरी लाइब्रेरीज के स्थानीय संस्करण का उपयोग
  • अस्थायी रूप से वैकल्पिक कार्यान्वयनों पर स्विच करना

मल्टी-वर्जन परीक्षण

अपने लाइब्रेरी को एक निर्भरता के कई संस्करणों के खिलाफ परीक्षण करें:

# टर्मिनल 1: निर्भरता v1.x के साथ परीक्षण
GOWORK=off go test ./...

# टर्मिनल 2: स्थानीय संशोधित निर्भरता के साथ परीक्षण
go test ./...  # go.work का उपयोग करता है

वेंडर डायरेक्टरी के साथ वर्कस्पेस

वर्कस्पेस और वेंडरिंग साथ-साथ coexist कर सकते हैं:

go work vendor

यह पूरे वर्कस्पेस के लिए एक वेंडर डायरेक्टरी बनाता है, जो एयर-गैप्ड वातावरणों या ऑफ़लाइन पुनरुत्पाद्य बिल्ड्स के लिए उपयोगी है।

IDE एकीकरण

अधिकांश IDEs Go वर्कस्पेस का समर्थन करते हैं:

VS Code: Go एक्सटेंशन इंस्टॉल करें। यह स्वचालित रूप से go.work फाइलों का पता लगाता है।

GoLand: वर्कस्पेस रूट डायरेक्टरी खोलें। GoLand go.work को पहचानता है और प्रोजेक्ट के अनुसार कॉन्फ़िगर करता है।

Vim/Neovim के साथ gopls: gopls भाषा सर्वर स्वचालित रूप से go.work का सम्मान करता है।

अगर आपका IDE “मॉड्यूल नहीं मिला” त्रुटियाँ दिखाता है despite एक सही वर्कस्पेस, तो प्रयास करें:

  • भाषा सर्वर को रीस्टार्ट करें
  • सुनिश्चित करें कि आपकी go.work पथ सही हैं
  • सुनिश्चित करें कि gopls अप-टू-डेट है

GOPATH से मॉड्यूल्स में माइग्रेशन

अगर आप अभी भी GOPATH का उपयोग कर रहे हैं, तो यहां एक सुचारू माइग्रेशन के लिए चरण-दर-चरण मार्गदर्शिका है:

चरण 1: Go को अपडेट करें

सुनिश्चित करें कि आप Go 1.18 या उससे अधिक चलाते हैं:

go version

चरण 2: प्रोजेक्ट्स को GOPATH से बाहर ले जाएँ

आपके प्रोजेक्ट्स को अब $GOPATH/src में रहने की आवश्यकता नहीं है। उन्हें कहीं भी ले जाएँ:

mv $GOPATH/src/github.com/me/myproject ~/dev/myproject

चरण 3: मॉड्यूल्स को इनिशियलाइज़ करें

हर प्रोजेक्ट में:

cd ~/dev/myproject
go mod init github.com/me/myproject

अगर प्रोजेक्ट ने dep, glide, या vendor का उपयोग किया, तो go mod init स्वचालित रूप से निर्भरताओं को go.mod में परिवर्तित करेगा।

चरण 4: निर्भरताओं को साफ़ करें

go mod tidy      # अनुपयोगी निर्भरताओं को हटाएँ
go mod verify    # चेकसम्स की पुष्टि करें

चरण 5: आयात पथों को अपडेट करें

अगर आपका मॉड्यूल पथ बदल गया है, तो अपने पूरे कोडबेस में आयात्स को अपडेट करें। उपकरणों जैसे gofmt और goimports मदद करते हैं:

gofmt -w .
goimports -w .

चरण 6: व्यापक रूप से परीक्षण करें

go test ./...
go build ./...

सुनिश्चित करें कि सब कुछ कॉम्पाइल होता है और टेस्ट पास होते हैं। प्रभावी ढंग से अपने टेस्ट संरचित करने के लिए व्यापक मार्गदर्शिका के लिए देखें Go Unit Testing: Structure & Best Practices।

चरण 7: CI/CD को अपडेट करें

अपने CI/CD स्क्रिप्ट्स से GOPATH-विशिष्ट पर्यावरण चरों को हटाएँ। आधुनिक Go बिल्ड्स उन्हें नहीं चाहते:

# पुराना (GOPATH)
env:
  GOPATH: /go
  PATH: /go/bin:$PATH

# नया (Modules)
env:
  GO111MODULE: on  # Go 1.13+ में डिफ़ॉल्ट, वैकल्पिक

चरण 8: GOPATH को साफ़ करें (वैकल्पिक)

पूर्ण रूप से माइग्रेट होने के बाद, आप GOPATH डायरेक्टरी को हटा सकते हैं:

rm -rf $GOPATH
unset GOPATH  # .bashrc या .zshrc में जोड़ें

सर्वोत्तम प्रथाओं का सारांश

  1. नए प्रोजेक्ट्स के लिए मॉड्यूल्स का उपयोग करें: वे Go 1.13 से मानक हैं और बेहतर निर्भरता प्रबंधन प्रदान करते हैं।

  2. केवल आवश्यकता पड़ने पर वर्कस्पेस बनाएँ: मल्टी-मॉड्यूल विकास के लिए go.work का उपयोग करें। एकल प्रोजेक्ट्स को इसकी आवश्यकता नहीं है।

  3. go.work फाइलों को कभी कमिट न करें: वे व्यक्तिगत विकास उपकरण हैं, न कि प्रोजेक्ट आर्टिफैक्ट्स।

  4. प्रोजेक्ट्स को तर्कसंगत रूप से संगठित करें: डोमेन, क्लाइंट, या उद्देश्य के अनुसार समूहित करें। हायरार्की को शैली में रखें।

  5. अपनी वर्कस्पेस संरचना का दस्तावेजीकरण करें: README फाइलों जोड़ें जो संगठन का वर्णन करें।

  6. वर्कस्पेस के बिना समय-समय पर परीक्षण करें: सुनिश्चित करें कि आपका कोड go.work सक्रिय नहीं होने पर सही ढंग से बिल्ड होता है।

  7. वर्कस्पेस को केंद्रित रखें: केवल निकटता से संबंधित, परस्पर निर्भर मॉड्यूल्स शामिल करें।

  8. रिप्लेस डायरेक्टिव्स का सावधानीपूर्वक उपयोग करें: स्थानीय रिप्लेस के लिए go.work में रखें, न कि go.mod में।

  9. go work sync चलाएँ: अपने वर्कस्पेस मेटाडेटा को मॉड्यूल निर्भरताओं के साथ संगत रखें।

  10. Go संस्करणों के साथ अप-टू-डेट रहें: वर्कस्पेस फीचर्स हर रिलीज़ के साथ सुधारते हैं।

उपयोगी लिंक