تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دليل 101 حول Cloud Foundation

1. مقدمة عن CFT 101

تاريخ التعديل الأخير: 11-02-2022

ما هي مجموعة أدوات Cloud Foundation؟

في الأساس، يوفّر CFT نماذج لأفضل الممارسات من أجل البدء بسرعة في Google Cloud Platform. ستتعرّف في هذا البرنامج التعليمي على كيفية المساهمة في مجموعة أدوات Cloud Foundation.

المتطلبات

حساب على GitHub
يجب تثبيت Docker على جهازك أو استخدام Cloud Shell ( تثبيت على نظام التشغيل Mac، تثبيت على نظام التشغيل Windows).
أداة تعديل الرموز لتعديل الرمز (مثال: Visual Studio Code)
معرفة أساسية بـ Git وGitHub
بعض الخبرة في Terraform و"ترميز برامج وتطبيقات البنية الأساسية"
الإذن بمنح دور "صانع المشروع" لحساب خدمة
مؤسسة على Google Cloud وملف اختبار وحساب فوترة

التطبيق الذي ستصممه

في هذا الدليل التعليمي حول الرموز البرمجية، ستتعرّف على كيفية المساهمة في حزمة Cloud Foundation Toolkit (CFT).

ويمكنك إجراء ما يلي:

إعداد بيئة تطوير للمساهمة في CFT
إضافة ميزة إلى وحدة CFT
إضافة اختبارات للميزة المُضافة
إجراء اختبارات التكامل في واجهة CFT
تنفيذ اختبارات التدقيق
إرسال الرمز إلى GitHub وإرسال طلب سحب

يمكنك تنفيذ جميع الخطوات أعلاه عن طريق إضافة ميزة جديدة إلى وحدة CFT في Google Cloud Storage. ستضيف تصنيفًا باسم "silly_label"، وسيتمّت إضافته تلقائيًا إلى جميع الحِزم التي تمّ إنشاؤها من خلال وحدة CFT في GCS. ستتمكّن أيضًا من كتابة اختبارات للتحقّق من صحتها وضمان الدمج الشامل.

2. إعداد بيئة المطوّر

يمكنك استخدام Cloud Shell لأغراض التطوير إذا أردت. إذا كنت لا تريد استخدام Cloud Shell للمساهمة في CFT، يمكنك إعداد بيئة التطوير على جهازك.

إعداد Git

يستند GitHub إلى نظام تحكم في الإصدارات (VCS) مفتوح المصدر يُسمى Git. يكون Git مسؤولاً عن كل العمليات المتعلّقة بـ GitHub والتي تحدث محليًا على جهازك أو Cloud Shell.

عند استخدام Cloud Shell، لن تحتاج إلى تثبيت git حيث تتوفّر تثبيته مسبقًا.

$ git --version
# This will display the git version on the Cloud Shell.

إذا كنت تقوم بإعداد بيئة مطوري البرامج على جهازك، فأنت بحاجة إلى تثبيت Git.

ضبط اسم المستخدم وعنوان البريد الإلكتروني في Git

يستخدم Git اسم مستخدم لربط عمليات الإضافة بهوية. يختلف اسم مستخدم Git عن اسم المستخدم في GitHub.

يمكنك تغيير الاسم المرتبط بإرسالات Git باستخدام الأمر git config. إنّ تغيير الاسم المرتبط بـ Git الذي يلتزم به باستخدام git config سيؤثر فقط في التزاماتك المستقبلية ولن يؤدي إلى تغيير الاسم المستخدَم في عمليات الربط السابقة.

لقد أعددت Git بنجاح ومن المفترض أن تتمكّن من إنشاء فروع ونسخها وإنشاء فروع منها. سنستخدم Git على نطاق واسع في هذا الدرس التطبيقي حول الترميز.

3- نسخة CFT من مستودع GCS

إنشاء نسخة من مستودع CFT

لقد أعددت Git على جهازك المحلي أو على Cloud Shell في الخطوة السابقة. عليك الآن إنشاء نسخة من مستودع CFT في Google Cloud Storage لبدء المساهمة.

الإصدار المشتق هو نسخة من مستودع. يتيح لك إنشاء نسخة من مستودع تجربة التغييرات بحرية بدون التأثير في المشروع الأصلي.

في أغلب الأحيان، يتم استخدام النسخ المشتقة لتقديم تغييرات على مشروع شخص آخر أو استخدام مشروع شخص آخر كنقطة بداية لتطبيق فكرتك.

على سبيل المثال، يمكنك استخدام الإصدارات المشتقة لاقتراح تغييرات متعلّقة بإصلاح خطأ. لإصلاح خطأ، يمكنك إجراء ما يلي:

انسخ المستودع.
عليك إجراء الإصلاح.
أرسِل طلب سحب إلى مالك المشروع.

خطوات إنشاء نسخة من مستودع CFT:

افتح متصفّح الويب وانتقِل إلى مستودع terraform-google-modules/terraform-google-cloud-storage. سنستخدم هذا المستودع للدرس التطبيقي حول الترميز بالكامل.
في أعلى يسار الصفحة، انقر على إنشاء نسخة.

سيظهر لك خيار تحديد المكان الذي تريد إنشاء النسخة المشتقة منه، واختَر ملفك الشخصي وسيتم إنشاء نسخة مشتقة من المستودع.

نسخ نسختك المشتقة على الجهاز

النسخة التي أنشأتها هي نسخة من مستودع وحدة GCS. ستنسخ الآن هذا المستودع إلى بيئتك المحلية لإضافة الميزة الجديدة.

خطوات استنساخ النسخة المشتقة:

افتح متصفّح الويب وانتقِل إلى النسخة المزوّدة بالتعديلات على terraform-google-modules/terraform-google-cloud-storage.
في أعلى يسار الشاشة، سيظهر لك الزر "الرمز"، انقر عليه.

بعد النقر على الزر "الرمز"، انقر على رمز "النسخ" لنسخ عنوان URL لنسخة التطبيق المشتقة. ستستخدم عنوان URL هذا لاستنساخ شوكتك إلى بيئتك المحلية.

انتقِل إلى وحدة طرفية في VSCode أو جهازك وانسخ الإصدار المشتق.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

الآن بعد أن استنسخت شوكتك محليًا، يجب عليك الانتقال إلى مستودعك، وإنشاء فرع جديد من الشوكة وإجراء تغييرات على التعليمات البرمجية للفرع المؤقت.

حسب الاصطلاح، يمكنك تسمية الفرع على النحو التالي:

لطلبات الميزات: feature/feature-name
بالنسبة إلى التعديلات الداخلية، يُرجى التواصل مع internal/change-name.
بالنسبة إلى إصلاحات الأخطاء: bugfix/issue-name

بما أنّك بصدد إضافة ميزة جديدة، يمكنك تسمية فرعك المؤقت feature/silly_label.

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

لقد اكتملت الآن عملية الإعداد لبدء العمل على Cloud Foundation Toolkit.

4. إنشاء بيئة اختبار

تستند عملية تطوير CFT العادية إلى استخدام مشروع اختبار معزول للاختبار. سترشدك هذه الخطوة خلال إنشاء المشروع التجريبي (استنادًا إلى إعدادات عادية) من خلال حساب خدمة.

0. تثبيت Docker Engine

إذا كنت تستخدم جهازك لأغراض التطوير، عليك تثبيت Docker Engine.

1. تثبيت Google Cloud SDK

لست بحاجة إلى تثبيت Google Cloud SDK إذا كنت تستخدم Cloud Shell في Google Cloud Platform.

انتقِل إلى Google Cloud SDK ونزِّل أداة التثبيت التفاعلي لنظامك الأساسي.

2- ضبط الإعدادات

لإنشاء بيئة اختبار، ستحتاج إلى مؤسسة على Google Cloud ومجلد اختبار وحساب فوترة. يجب ضبط هذه القيم من خلال متغيّرات البيئة:

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. إعداد حساب الخدمة

قبل إنشاء بيئة اختبار، عليك تنزيل مفتاح حساب الخدمة إلى بيئتك الاختبارية. سيحتاج حساب الخدمة هذا إلى أدوار صانع المشروع ومستخدم حساب الفوترة ومُشاهد المؤسسة. تساعدك هذه الخطوات في إنشاء حساب خدمة جديد، ولكن يمكنك أيضًا إعادة استخدام حساب حالي.

3.1 إنشاء مشروع أوّلي في Google Cloud Platform أو اختياره

قبل إنشاء حساب الخدمة، يجب اختيار مشروع لاستضافتها فيه. يمكنك أيضًا إنشاء مشروع جديد.

gcloud config set core/project YOUR_PROJECT_ID

3.2 تفعيل Google Cloud APIs

فعِّل واجهات برمجة تطبيقات Google Cloud التالية في مشروعك التمهيدي:

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 إنشاء حساب خدمة

أنشئ حساب خدمة جديدًا لإدارة بيئة الاختبار:

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

تأكَّد من إنشاء حساب الخدمة:

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 منح أدوار "صانع المشروع" و"مستخدم حساب الفوترة" و"مُشاهد المؤسسة" لحساب الخدمة:

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

لديك الآن حساب خدمة يمكن استخدامه لإدارة بيئة الاختبار.

4. إعداد بيانات اعتماد Terraform

لإنشاء بيئة اختبار، عليك تنزيل مفتاح حساب الخدمة في واجهة الأوامر.

4.1 مفتاح حساب الخدمة

إنشاء مفتاح حساب خدمة وتنزيله لاستخدامه مع Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 إعداد بيانات اعتماد Terraform

أدخِل المفتاح إلى Terraform باستخدام متغير البيئة SERVICE_ACCOUNT_JSON، مع ضبط القيمة على contents لمفتاح حساب الخدمة.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

بعد تخزين معلومات بيانات الاعتماد في متغيّر البيئة، أزِل ملف المفاتيح. يمكنك إعادة إنشاء مفتاح لاحقًا إذا لزم الأمر باستخدام الأمر نفسه أعلاه.

rm -rf cft.json

5- إنشاء مشروع اختباري لعمليات نشر Terraform

بعد أن تم إعداد كل شيء، يمكنك إنشاء المشروع التجريبي باستخدام أمر واحد. شغِّل هذا الأمر من جذر دليل terraform-google-cloud-storage:

make docker_test_prepare

ستظهر لك النتائج أدناه عند تشغيل make docker_test_prepare، وفي النهاية ستتلقّى معرّف مشروع الاختبار الذي تم إنشاؤه حيث سيتم نشر وحدة Cloud Storage واختبارها باستخدام الميزة الجديدة. إذا واجهت مشاكل في ربط حساب فوترة، يمكنك الرجوع إلى خطوات تحديد المشاكل وحلّها.

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

لقد أنشأت الآن مشروعًا تجريبيًا تتم الإشارة إليه من خلال project_id كما هو موضّح في إخراج وحدة التحكّم. تم إعداد بيئة التطوير والاختبار.

5- إضافة ميزة جديدة إلى وحدة CFT

بعد إعداد بيئة التطوير والاختبار، لنبدأ بإضافة ميزة "silly_label" إلى وحدة CFT في google-cloud-storage.

تأكَّد من أنّك في terraform-google-cloud-storage وافتح ملف main.tf كما هو موضّح أدناه في بنية المجلد.

بما أنّ "silly_label" هو تصنيف، ستضيف العنصر في السطر 27 في المتغيّر "labels" في main.tf، كما هو موضّح أدناه:

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

الآن، ستضيف المتغير silly_label في ratings.tf الذي تراه في هيكل المجلد أعلاه.

انسخ الرمز البرمجي أدناه والصقه في السطر 31 من variables.tf وتأكّد من توفّر حرف سطر جديد أعلى وتحت مجموعة المتغيّرات التي تضيفها.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6- إضافة ميزة جديدة إلى مثال حزمة التخزين

لقد أضفت ميزتك إلى main.tf في الوحدة، ويمكنك الآن اختبار الميزة المُضافة من خلال مثال.

يجب إضافة "silly_label" إلى الأمثلة/Multiple-buckets/main.tf.

سيتم استخدام هذا المثال في الخطوة التالية لإجراء اختبارات الدمج.

انسخ سطر المتغيّر silly_label أدناه والصقه في السطر 27 من main.tf في terraform-google-cloud-storage/examples/multiple-buckets/ كما هو موضّح في بنية المجلد:

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7- تعديل اختبار المخطّط للتحقق من الميزة

لقد أضفت ميزتك إلى main.tf للوحدة، ثم أضفت الميزة إلى مثال multiple_buckets. الآن، تحتاج إلى اختبار الميزة من خلال اختبار دمج مخطط مكتوب بلغة Golang.

ستضيف اختباراتك الجديدة في ملف multiple_buckets_test.go المتوفّر في بنية المجلد أدناه:

لقد أضفت العلامة silly_label على جميع الحِزم التي يتم إنشاؤها من خلال وحدة multiple_buckets، وعليك الآن كتابة اختبارات لاختبار الميزة الجديدة.

في التعليمة البرمجية أدناه، تحصل على تسمية كل حزمة من خلال أمر gcloud alpha Storage ثم تتحقق من النتيجة التي تم إرجاعها من الأمر.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. تنفيذ اختبارات الدمج في CFT

اختبار الدمج

تُستخدم اختبارات الدمج للتحقق من سلوك الوحدة الجذر والوحدات الفرعية والأمثلة. يجب أن تكون التعديلات والتغييرات والإصلاحات مصحوبة باختبارات.

يتم كتابة اختبارات الدمج باستخدام إطار عمل اختبار المخطّط وتشغيلها باستخدام واجهة برمجة التطبيقات CFT. يتم تجميع هذه الأدوات داخل صورة Docker لتسهيل العملية.

تتمثل الاستراتيجية العامة لهذه الاختبارات في التحقّق من سلوك وحدات الأمثلة، وبالتالي التأكّد من أنّ الوحدة الرئيسية والوحدات الفرعية ووحدات الأمثلة تعمل بشكل صحيح.

في التنفيذ التفاعلي، يمكنك تنفيذ كل خطوة من خلال أوامر متعددة.

شغِّل make docker_run لبدء اختبار حاوية Docker في الوضع التفاعلي.

‫Make هي أداة لإنشاء البرامج المبرمَجة تلقائيًا من الرموز البرمجية المصدر من خلال قراءة ملفات تُعرف باسم ملفات التصنيع التي تحدّد كيفية إنشاء البرنامج المستهدَف. عند إجراء تغييرات على الملفات، يجب تعديل حاوية Docker تلقائيًا.

عند تشغيل make docker_run، يتم إنشاء مساحة عمل في حاوية Docker وتفعيل بيانات اعتماد حساب الخدمة. سيتم استخدام مساحة العمل في الخطوات التالية لإجراء الاختبارات.

سيظهر لك الإخراج أدناه في وحدة التحكّم الطرفية:

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

نفِّذ cft test list لسرد جميع اختبارات المخططات في مساحة العمل.

سيظهر لك الإخراج أدناه في وحدة التحكّم الطرفية:

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go

شغِّل cft test run <EXAMPLE_NAME> --stage init لبدء المثال. في هذه الحالة، لبدء تشغيل اختبار TestMultipleBuckets، cft test run TestMultipleBuckets --stage init. يمكنك أيضًا استخدام العلامة --verbose للحصول على معلومات إضافية عند إجراء الاختبارات.

تعمل مرحلة الإعداد هذه على إعداد مثال Terraform.

سيظهر لك الإخراج أدناه في وحدة التحكّم الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

شغِّل cft test run <EXAMPLE_NAME> --stage apply لتطبيق نموذج الوحدة.

تطبّق هذه الخطوة المثال الذي تم إعداده في المرحلة السابقة على مشروع GCP الذي تم إنشاؤه سابقًا في Codelab.

سيظهر الناتج أدناه في الوحدة الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

شغِّل cft test run <EXAMPLE_NAME> --stage verify للتأكّد من أنّ المثال أنشأ البنية الأساسية المتوقّعة.

ستؤدي هذه الخطوة إلى تشغيل دالة التحقّق في TestMultipleBuckets. يتم عادةً التحقّق من خلال تنفيذ أمر gcloud لاسترداد إخراج JSON للحالة الحالية لمورد معيّن والتأكّد من أنّ الحالة الحالية كما هو موضّح في المثال.

إذا ظهرت لك أي أخطاء، سترى ما كان متوقّعًا وما تم تلقّيه من خلال الأمر الخاص بالاختبار.

سيظهر لك الإخراج أدناه في وحدة التحكّم الطرفية.

cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

شغِّل cft test run <EXAMPLE_NAME> --stage teardown لإزالة المثال.

تؤدي هذه الخطوة إلى تدمير البنية التحتية التي أنشأتها في الخطوات أعلاه. ستؤدي هذه الخطوة أيضًا إلى تدمير حِزم GCS التي تم إنشاؤها في المشروع بالإضافة إلى التصنيف الذي أضفته إلى وحدة GCS.

يمكنك الاطّلاع على الإخراج أدناه في وحدة التحكّم الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

شغِّل exit للخروج من الحاوية الاختبارية.

9. إنشاء وثائق للمدخلات والمخرجات

يتم إنشاء جداول "المدخلات" و"المخرجات" في ملفات README الخاصة بالوحدة الرئيسية والوحدات الفرعية والأمثلة على الوحدات تلقائيًا استنادًا إلى variables وoutputs للوحدات المعنية. يجب إعادة تحميل هذه الجداول في حال تغيير واجهات الوحدات.

تنفيذ:

make generate_docs
# This will generate new Inputs and Outputs tables

10. تنفيذ اختبارات التدقيق في CFT

linter هي أداة تحلِّل رمز المصدر لوضع علامة على الأخطاء البرمجية والأخطاء في الأسلوب والتركيبات المريبة.

يمكن فحص العديد من الملفات في المستودع أو تنسيقها للحفاظ على مستوى الجودة. لضمان الجودة في CFT، يجب استخدام اختبار الوبر.

تنفيذ:

make docker_test_lint
# This will run all lint tests on your repo

11. إرسال طلب إعادة نظر على GitHub

الآن بعد أن غيّرت رمزك محليًا واختبرته من خلال اختبارات الدمج، ستحتاج إلى نشر هذا الرمز في المستودع الرئيسي.

لتوفير الرمز في المستودع الرئيسي، عليك الالتزام بتغييرات الرمز في فرعك ودفعها إلى المستودع الرئيسي. لإضافة الرمز إلى المستودع الرئيسي الذي أنشأته في بداية "الدرس التطبيقي حول الترميز"، عليك تقديم "طلب سحب" (PR) في المستودع الرئيسي بعد تطبيق الرمز عليه.

عند إرسال طلب إعادة نظر، سيتم إشعار مشرف المستودع لمراجعة التغييرات المقترَحة على الرمز البرمجي. بالإضافة إلى ذلك، يمكنك أيضًا إضافة مستخدمين آخرين كمراجعين للحصول على ملاحظات حول تغييرات الرمز البرمجي. سيؤدي طلب المراجعة إلى بدء عملية إنشاء في Cloud ستُجري اختبارات على المستودع.

استنادًا إلى التغييرات التي أجريتها على الرمز، سيقدّم مراجعو الرمز تعليقات حول الرمز وسيطلبون إجراء تعديلات إذا كان هناك حاجة إلى تغيير أيّ شيء استنادًا إلى أفضل الممارسات والمستندات. سيراجع المشرف التغييرات التي أجريتها على الرمز، وسيتأكّد من توافق الرمز مع المستودع، وقد يطلب منك مرة أخرى إجراء بعض التغييرات قبل دمج الرمز في المستودع الرئيسي.

نفِّذ الخطوات التالية لإرسال الرمز إلى الفرع المنسوخ ودفعه إلى الفرع المنسوخ:

الخطوة الأولى هي إضافة الملفات التي تم تغييرها إلى المستودع المحلي.

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

يتم الآن ترتيب ملفاتك، وبعد ذلك ستلتزم بالتغييرات.

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

ادفع التغييرات التي تم الالتزام بها في مستودعك المحلي إلى GitHub لإنشاء طلب سحب (PR).

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

أصبحت تغييرات الرمز البرمجي جاهزة الآن لإرسال طلب سحب.

نفِّذ الخطوات التالية لإنشاء طلب إعادة نظر في terraform-google-modules/terraform-google-cloud-storage المستودع:

في متصفّح الويب، انتقِل إلى الصفحة الرئيسية للمستودع.
سيظهر لك اقتراح عبر بانر لفتح طلب إعادة نظر من خلال نسختك المشتقة. انقر على "مقارنة الطلب وسحبه".

أدخِل عنوانًا ووصفًا لطلب سحب التغييرات لوصف تغييرات الرمز البرمجي. يُرجى تقديم وصف دقيق وموجز قدر الإمكان.

لإنشاء طلب سحب جاهز للمراجعة، انقر على "إنشاء طلب سحب".
سترى مشغّلات Cloud Build التي يتم تشغيلها بسبب طلب التغيير.
يمكنك الرجوع إلى مستندات GitHub الرسمية حول فتح طلبات سحب من فروع في حال مواجهة أي مشاكل.

لقد أرسلت بنجاح أول تغيير في الرمز البرمجي إلى الفرع المشتق وأرسلت أول طلب إعادة نظر في CFT في الفرع الرئيسي.

12. تهانينا

تهانينا، لقد أضفت بنجاح ميزة إلى وحدة CFT وأرسلت "PR" للمراجعة.

أضفت ميزة إلى وحدة CFT واختبرت هذه الميزة محليًا من خلال مثال، وأجريت الاختبارات قبل إرسال الرمز إلى GitHub. أخيرًا، أرسلت طلبًا لمراجعة الإصدار ودمجه نهائيًا في CFT.

لقد تعرّفت الآن على الخطوات المهمة لبدء استخدام "مجموعة أدوات Cloud Foundation".