اذهب إلى أدوات و GitLab - كيفية القيام بالتكامل المستمر مثل الرئيس

الصورة التي تود Quackenbush على Unsplash

في Pantomath ، نستخدم GitLab لجميع أعمال التطوير لدينا. ليس الغرض من هذه الورقة تقديم GitLab وجميع ميزاته ، بل تقديم كيفية استخدامنا لهذه الأدوات لتخفيف حياتنا.

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

كل الشفرة التي تظهر في هذا المنشور متاحة على https://gitlab.com/pantomath-io/demo-tools. لذلك لا تتردد في الحصول على مستودع ، واستخدام العلامات للتنقل فيه. يجب وضع المستودع في مجلد src الخاص بـ GOPATH $:

$ go get -v -d gitlab.com/pantomath-io/demo-tools
$ cd $ GOPATH / src / gitlab.com / pantomath-io / demo tools

الذهاب الأدوات

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

قائمة الحزمة

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

قائمة الذهاب دولار. / ...

لاحظ أننا نريد تجنب تطبيق أدواتنا على الموارد الخارجية ، وقصرها على الكود الخاص بنا. لذلك نحن بحاجة إلى التخلص من أدلة البائعين:

قائمة الذهاب $. / ... | grep -v / بائع /

الوبر

هذه هي الأداة الأولى التي نستخدمها على الكود: linter. دورها هو التأكد من أن الكود يحترم نمط الكود. قد يبدو هذا وكأنه أداة اختيارية ، أو على الأقل "أداة لطيفة" ، لكنه يساعد حقًا في الحفاظ على أسلوب ثابت على مشروعك.

لا يمثل هذا الطير جزءًا من عملية الانتقال في حد ذاتها ، لذلك تحتاج إلى الاستيلاء عليها وتثبيتها يدويًا (انظر المستند الرسمي).

الاستخدام بسيط إلى حد ما: يمكنك تشغيله فقط على حزم التعليمات البرمجية الخاصة بك (يمكنك أيضًا توجيه ملفات .go):

$ golint -set_exit_status $ (اذهب إلى القائمة. / ... | grep -v / بائع /)

لاحظ الخيار -set_exit_status. بشكل افتراضي ، تطبع golint مشكلات النمط فقط ، وتعود (برمز الإرجاع 0) ، لذا فإن CI لا ترى شيئًا ما حدث خطأ. إذا حددت -set_exit_status ، فسيكون رمز الإرجاع من golint مختلفًا عن 0 في حالة مواجهة أي مشكلة في النمط.

اختبار الوحدة

هذه هي الاختبارات الأكثر شيوعًا التي يمكنك تشغيلها على الكود. لكل ملف .go ، نحتاج إلى ملف _test.go مرتبط به اختبارات الوحدة. يمكنك إجراء الاختبارات لجميع الحزم باستخدام الأمر التالي:

$ go test -short $ (اذهب إلى القائمة. / ... | grep -v / بائع /)

سباق البيانات

غالبًا ما يكون هذا موضوعًا صعبًا للتغطية ، لكن أداة الانتقال به افتراضيًا (لكن تتوفر فقط على نظام التشغيل linux / amd64 و freebsd / amd64 و darwin / amd64 و windows / amd64). لمزيد من المعلومات حول سباق البيانات ، راجع هذه المقالة. في هذه الأثناء ، إليك كيفية تشغيله:

$ go test -race -short $ (اذهب إلى القائمة. / ... | grep -v / بائع /)

المطهر الذاكرة

يحتوي Clang على كاشف لطيف للقراءة غير المهيأة التي تسمى MemorySanitizer. تعتبر أداة go go جيدة بدرجة كافية للتفاعل مع وحدة Clang (بمجرد تشغيل مضيف linux / amd64 واستخدام إصدار حديث من Clang / LLVM (> = 3.8.0). هذا الأمر هو كيفية تشغيله:

$ go test -msan -short $ (اذهب إلى القائمة. / ... | grep -v / بائع /)

مدونة التغطية

هذا أيضًا أمر لا بد منه لتقييم صحة الكود الخاص بك ، ومعرفة ما هو جزء الكود من اختبارات الوحدة وما هو الجزء الذي لا. روب بايك كتب وظيفة كاملة عن هذا الموضوع بالذات.

لحساب نسبة تغطية الشفرة ، نحتاج إلى تشغيل البرنامج النصي التالي:

PKG_LIST $ = $ (اذهب إلى القائمة. / ... | grep -v / vendor /)
$ للحزمة بـ $ {PKG_LIST} ؛ فعل
    go test -covermode = count -coverprofile "cover / $ {package ## * /}. cov" "$ package"؛
فعله
$ tail -q -n +2 cover / *. cov >> cover / Cover.cov
$ go tool cover -func = cover / cover.cov

إذا كنا نريد الحصول على تقرير التغطية بتنسيق HTML ، فسنحتاج إلى إضافة الأمر التالي:

$ go tool cover -html = cover / Cover.cov -o Cover.html

بناء

أخيرًا وليس آخرًا ، بمجرد اختبار الكود بالكامل ، قد نرغب في تجميعه لجعله قادرًا على بناء ثنائي فعال.

$ go build -i -v gitlab.com/pantomath-io/demo-tools

ماكيفيلي

بوابة العلامة: init-makefile

الصورة من قبل مات ارتز على Unsplash

الآن لدينا جميع الأدوات التي قد نستخدمها في سياق التكامل المستمر ، يمكننا أن نلفها جميعًا في Makefile ، ولدينا طريقة ثابتة للاتصال بها.

ليس الغرض من هذا المستند تقديم تقديم ، ولكن يمكنك الرجوع إلى الوثائق الرسمية لمعرفة المزيد عنها.

PROJECT_NAME: = "الأدوات التجريبية"
PKG: = "gitlab.com/pantomath-io/$(PROJECT_NAME)"
PKG_LIST: = $ (shell go list $ {PKG} / ... | grep -v / vendor /)
GO_FILES: = $ (العثور على shell. -name '* .go' | grep -v / vendor / | grep -v _test.go)
.PHONY: جميع dep بناء نظيفة تغطية تغطية coverhtml الوبر
كل شيء: بناء
الوبر: ## الوبر الملفات
 golint -set_exit_status $ {PKG_LIST}
اختبار: ## تشغيل unittests
 go test -short $ {PKG_LIST}
race: dep ## قم بتشغيل كاشف سباق البيانات
 go test -race -short $ {PKG_LIST}
msan: dep ## قم بتشغيل الذاكرة المطهرة
 go test -msan -short $ {PKG_LIST}
التغطية: ## قم بإنشاء تقرير تغطية الرمز العالمي
 ./tools/coverage.sh.
coverhtml: ## قم بإنشاء تقرير تغطية التعليمات البرمجية العالمية بتنسيق HTML
 ./tools/coverage.sh html؛
dep: ## احصل على التبعيات
 go get -v -d / ...
build: dep ## قم ببناء الملف الثنائي
 go build -i -v $ (PKG)
تنظيف: ## إزالة البناء السابق
 rm -f $ (PROJECT_NAME)
help: ## عرض شاشة المساعدة هذه
 grep -h -E '^ [a-zA-Z _-] +:. *؟ ##. * $$' $ (MAKEFILE_LIST) | awk 'BEGIN {FS = ":. *؟ ##"}؛ {printf "\ 033 [36m٪ -30s \ 033 [0m٪ s \ n"، $$ 1، $$ 2} '

ماذا لدينا الآن؟ هدف واحد لأي أداة سبق تقديمها ، و 3 أهداف أخرى من أجل:

  • تركيب التبعيات (dep) ؛
  • التدبير المنزلي للمشروع (نظيفة) ؛
  • بعض المساعدة لطيفة وبراقة (مساعدة).

لاحظ أنه كان علينا أيضًا إنشاء برنامج نصي لعمل تغطية الشفرة. هذا لأن تنفيذ الحلقات على الملفات في Makefile هو ألم. لذلك يتم العمل في برنامج نصي bash ، ويقوم ملف Makefile فقط بتشغيل هذا البرنامج النصي.

يمكنك تجربة Makefile باستخدام الأوامر التالية:

تقديم المساعدة
$ جعل الوبر
جعل التغطية

التكامل المستمر

بوابة العلامة: init-ci

الصورة بواسطة ماكس بنما على Unsplash

الآن أصبحت الأدوات في مكانها الصحيح ، ويمكننا إجراء اختبارات متنوعة على الشفرة الخاصة بنا ، ونود أن نتمكّن من تشغيلها تلقائيًا في مستودعك. لحسن الحظ ، GitLab تقدم خطوط أنابيب CI لهذا الغرض فقط. والإعداد لهذا الأمر بسيط جدًا: كل ما تقوم بإنشائه هو ملف .gitlab-ci.yml في جذر المستودع.

تعرض الوثائق الكاملة الموجودة في ملف Yaml جميع الخيارات ، ولكن يمكنك البدء بهذا .gitlab-ci.yml:

الصورة: جولانج: 1.9
مخبأ:
  مسارات:
    - / apt-cache
    - /go/src/github.com
    - /go/src/golang.org
    - /go/src/google.golang.org
    - /go/src/gopkg.in
مراحل:
  - اختبار
  - بناء
before_script:
  - mkdir -p /go/src/gitlab.com/pantomath-io / go / src / _ / builds
  - cp -r $ CI_PROJECT_DIR /go/src/gitlab.com/pantomath-io/pantomath
  - ln -s /go/src/gitlab.com/pantomath-io / go / src / _ / builds / pantomath-io
  - جعل dep
unit_tests:
  المرحلة: اختبار
  النصي:
    - جعل الاختبار
race_detector:
  المرحلة: اختبار
  النصي:
    - اصنع العرق
memory_sanitizer:
  المرحلة: اختبار
  النصي:
    - اجعل msan
مدونة التغطية:
  المرحلة: اختبار
  النصي:
    - جعل التغطية
code_coverage_report:
  المرحلة: اختبار
  النصي:
    - جعل الغلاف
  فقط:
  - رئيس
lint_code:
  المرحلة: اختبار
  النصي:
    - اصنع الوبر
بناء:
  المرحلة: بناء
  النصي:
    - يصنع

إذا قمت بتفكيك الملف ، فإليك بعض التوضيحات حول محتواه:

  • أول شيء هو اختيار صورة Docker التي سيتم استخدامها لتشغيل CI. توجه إلى Docker Hub لاختيار الصورة المناسبة لمشروعك.
  • بعد ذلك ، يمكنك تحديد بعض مجلدات هذه الصورة ليتم تخزينها مؤقتًا. الهدف هنا هو تجنب تنزيل نفس المحتوى عدة مرات. بمجرد اكتمال المهمة ، سيتم أرشفة المسارات المدرجة ، وستستخدم المهمة التالية نفس الأرشيف.
  • يمكنك تحديد المراحل المختلفة التي ستجمع وظائفك. في حالتنا ، لدينا مرحلتان (تتم معالجتها بهذا الترتيب): الاختبار والبناء. يمكن أن يكون لدينا مراحل أخرى ، مثل النشر.
  • يعرّف قسم before_script الأوامر التي سيتم تشغيلها في حاوية Docker قبل انتهاء المهمة فعليًا. في سياقنا ، الأوامر فقط قم بنسخ أو ربط مستودع التخزين المنشور في GOPATH $ ، وتثبيت التبعيات.
  • ثم تأتي الوظائف الفعلية ، وذلك باستخدام أهداف Makefile. لاحظ الحالة الخاصة لـ code_coverage_report حيث يقتصر التنفيذ على الفرع الرئيسي (لا نريد تحديث تقرير تغطية الشفرة من فروع الميزات على سبيل المثال).

أثناء التزامنا / بدفع ملف .gitlab-ci.yml في المستودع ، يتم تشغيل CI تلقائيًا. وفشل خط الأنابيب. كيف ذلك؟

تفشل مهمة lint_code لأنها لا تستطيع العثور على ملف golint الثنائي:

$ جعل الوبر
make: golint: الأمر غير موجود
Makefile: 11: وصفة الهدف "الوبر" فشلت
تقديم: *** [الوبر] خطأ 127

لذلك ، قم بتحديث Makefile الخاص بك لتثبيت golint كجزء من الهدف dep.

تفشل مهمة memory_sanitizer لأن مجلس التعاون الخليجي يشكو من:

$ جعل msan
# وقت التشغيل / cgo
gcc: error: وسيطة غير معترف بها لتهيئة-الخيار = "ذاكرة"
Makefile: 20: فشل وصفة الهدف 'msan'
make: *** [msan] خطأ 2

ولكن تذكر أننا بحاجة إلى استخدام Clang / LLVM> = 3.8.0 للاستمتاع بخيار -msan في أمر go test.

لدينا 2 خيارات هنا:

  • إما نقوم بإعداد Clang في المهمة (باستخدام before_script) ؛
  • أو نستخدم صورة Docker مع تثبيت Clang افتراضيًا.

الخيار الأول جميل ، لكن هذا يعني أن هذا الإعداد يتم لكل مهمة واحدة. هذا سيكون طويلاً ، يجب أن نفعل ذلك مرة واحدة وإلى الأبد. لذلك نحن نفضل الخيار الثاني ، وهو طريقة جيدة للعب مع GitLab Registry.

بوابة العلامة: استخدام الخاصة ، عامل ميناء

نحتاج إلى إنشاء ملف Dockerfile للحاوية (كالعادة: اقرأ الوثائق الرسمية لمزيد من الخيارات حولها):

# الصورة الأساسية: https://hub.docker.com/_/golang/
من جولانج: 1.9
المندوب جوليان أندريو 
# تثبيت golint
ENV GOPATH / الذهاب
ENV PATH $ {GOPATH} / bin: $ PATH
RUN go go get -u github.com/golang/lint/golint
# إضافة مفتاح مناسب لمستودع LLVM
RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | إضافة apt-key -
# إضافة مستودع LLVM المناسب
صدى RUN "deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-5.0 main" | كوم -A /etc/apt/sources.list
# تثبيت رنة من مستودع LLVM
RUN apt-get update && apt-get install -y - no-install-توصي \
    رنة 5.0
    && apt-get clean \
    && rm -rf / var / lib / apt / lists / * / tmp / * / var / tmp / *
# تعيين كلانغ كما CC الافتراضي
ENV set_clang /etc/profile.d/set-clang-cc.sh
RUN echo "export CC = clang-5.0" | tee -a $ {set_clang} && chmod a + x $ {set_clang}

الحاوية المبنية من Dockerfile ستستند إلى golang: 1.9 image (تلك المشار إليها في ملف .gitlab-ci.yml).

بينما نحن فيه ، نقوم بتثبيت golint في الحاوية ، لذلك لدينا المتاحة. ثم نتبع الطريقة الرسمية لتثبيت Clang 5.0 من مستودع LLVM.

الآن لدينا Dockerfile في مكانه ، نحتاج إلى بناء صورة الحاوية وجعلها متاحة لـ GitLab:

$ عامل ميناء تسجيل registry.gitlab.com
عامل بناء $ -t registry.gitlab.com/pantomath-io/demo-tools.
$ عامل ميناء دفع registry.gitlab.com/pantomath-io/demo-tools

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

ألقِ نظرة على السجل الخاص بمستودعك ، فسترى صورتك جاهزة للاستخدام. وللحصول على CI باستخدام صورتك ، تحتاج فقط إلى تحديث ملف .gitlab-ci.yml:

الصورة: جولانج: 1.9

يصبح

image: registry.gitlab.com/pantomath-io/demo-tools:latest

تفصيل أخير: يجب أن تخبر CI باستخدام المترجم المناسب (أي متغير البيئة CC) ، لذلك نضيف تهيئة التهيئة في ملف .gitlab-ci.yml:

تصدير CC = clang-5.0

بمجرد الانتهاء من التعديل ، سيؤدي الالتزام التالي إلى تشغيل خط الأنابيب ، والذي يعمل الآن:

https://gitlab.com/pantomath-io/demo-tools/pipelines/13497136

شارات

بوابة العلامة: الحرف الأول الشارات

صورة لجاكوب أوينز على Unsplash

الآن أصبحت الأدوات في مكانها الصحيح ، فكل التزام سيطلق مجموعة اختبار ، وربما تريد إظهارها ، وهذا شرعي :) أفضل طريقة للقيام بذلك هي استخدام الشارات ، وأفضل مكان هو ملف README.

قم بتحريره وأضف الشارات الأربعة التالية:

  • حالة البناء: حالة آخر خط أنابيب في الفرع الرئيسي:
[! [حالة البناء] (https://gitlab.com/pantomath-io/demo-tools/badges/master/build.svg)] (https://gitlab.com/pantomath-io/demo-tools/commits /رئيس)
  • تقرير التغطية: النسبة المئوية للرمز التي تغطيها الاختبارات
[! [تقرير التغطية] (https://gitlab.com/pantomath-io/demo-tools/badges/master/coverage.svg)] (https://gitlab.com/pantomath-io/demo-tools/commits /رئيس)
  • الذهاب تقرير بطاقة:
[! [Go Report Card] (https://goreportcard.com/badge/gitlab.com/pantomath-io/demo-tools)] (https://goreportcard.com/report/gitlab.com/pantomath-io/ عرض الأدوات)
  • رخصة:
[! [License MIT] (https://img.shields.io/badge/License-MIT-brightgreen.svg)] (https://img.shields.io/badge/License-MIT-brightgreen.svg)

يحتاج تقرير التغطية إلى تكوين خاص. تحتاج إلى إخبار GitLab بكيفية الحصول على تلك المعلومات ، مع مراعاة أن هناك وظيفة في CI تعرضها عند تشغيلها.
هناك تهيئة لتزويد GitLab بإعادة تسجيل ، تستخدم في إخراج أي وظيفة. في حالة تطابق regexp ، يعتبر GitLab أن المطابقة هي نتيجة تغطية الرمز.

لذا توجه إلى الإعدادات> CI / CD في مستودعك ، وانتقل لأسفل إلى إعداد تحليل اختبار التغطية في قسم إعدادات خطوط الأنابيب العامة ، واستخدم إعادة التسجيل التالية:

الكلية: \ ق + \ (البيانات \) \ ق + (\ د + \ د + \٪).

أنت جاهز تمامًا! توجه إلى نظرة عامة على مستودعك ، وانظر إلى README:

استنتاج

ماذا بعد؟ ربما المزيد من الاختبارات فيكم CI. يمكنك أيضًا إلقاء نظرة على القرص المضغوط (النشر المستمر) لأتمتة عمليات النشر الخاصة بك. يمكن إجراء الوثائق باستخدام GoDoc. لاحظ أنك تقوم بإنشاء تقرير تغطية باستخدام code_coverage_report ، لكن لا تستخدمه في CI. يمكنك جعل المهمة تقوم بنسخ ملف HTML إلى خادم ويب ، باستخدام scp (راجع هذه الوثائق حول كيفية استخدام مفاتيح SSH).

شكرا جزيلا لتشارلز فرانسوا الذي شارك في كتابة هذه الورقة و https://gitlab.com/pantomath-io/demo-tools.

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