RMT
1.0.0
RMT เป็นเครื่องมือที่มีประโยชน์ในการช่วยปล่อยซอฟต์แวร์เวอร์ชันใหม่ของคุณ คุณสามารถกำหนดประเภทของเครื่องกำเนิดรุ่นที่คุณต้องการใช้ (เช่นการกำหนดเวอร์ชันความหมาย) ซึ่งคุณต้องการจัดเก็บเวอร์ชัน (เช่นในไฟล์ changelog หรือเป็นแท็ก VCS) และรายการการกระทำที่ควรดำเนินการก่อนหรือหลัง เปิดตัวเวอร์ชันใหม่
ในการใช้ RMT ในโครงการของคุณคุณควรใช้นักแต่งเพลงเพื่อติดตั้งเป็น Dev-dependency เพียงไปที่ไดเรกทอรีรากของโครงการของคุณและดำเนินการ:
composer require --dev liip/rmt
จากนั้นคุณต้องเริ่มต้น RMT โดยเรียกใช้คำสั่งต่อไปนี้:
php vendor/liip/rmt/command.php init
คำสั่งนี้จะสร้างไฟล์กำหนดค่า .rmt.yml และสคริปต์ที่เรียกใช้งาน RMT ในโฟลเดอร์รูทของโครงการของคุณ ตอนนี้คุณสามารถเริ่มใช้ RMT ได้โดยดำเนินการ:
./RMT
เมื่อไปถึงที่นั่นตัวเลือกที่ดีที่สุดของคุณคือการเลือกหนึ่งในตัวอย่างการกำหนดค่าด้านล่างและปรับให้เข้ากับความต้องการของคุณ
หากคุณใช้เครื่องมือการกำหนดเวอร์ชันเราขอแนะนำให้เพิ่มทั้งสองไฟล์นักแต่งเพลง ( composer.json และ composer.lock ) ไฟล์การกำหนดค่า RMT ( .rmt.yml ) และสคริปต์ที่ปฏิบัติการ RMT ไดเรกทอรี vendor ควรถูกละเว้นเนื่องจากมีการเติมเมื่อใช้งานการ composer install
คุณสามารถเพิ่ม RMT ให้กับนักแต่งเพลงระดับโลกของคุณ JSON และมีให้ทั่วโลกสำหรับโครงการทั้งหมดของคุณ เพียงแค่เรียกใช้คำสั่งต่อไปนี้:
composer global require liip/rmt
ตรวจสอบให้แน่ใจว่าคุณมี ~/.composer/vendor/bin/ ในเส้นทาง $ ของคุณ
RMT สามารถติดตั้งผ่าน Phar-composer ซึ่งจำเป็นต้องติดตั้ง เครื่องมือที่มีประโยชน์นี้ช่วยให้คุณสร้างไฟล์ phar ที่เรียกใช้ได้จากแพ็คเกจนักแต่งเพลง
หากคุณติดตั้ง phar-composer คุณสามารถเรียกใช้:
sudo phar-composer install liip/RMT
และมี phar-composer build และติดตั้งไฟล์ phar ไปยังเส้นทาง $ ของคุณซึ่งจะช่วยให้คุณเรียกใช้เป็น rmt จากบรรทัดคำสั่งหรือคุณสามารถเรียกใช้
phar-composer build liip/RMT
และคัดลอกไฟล์ phar ที่เกิดขึ้นด้วยตนเองไปยังที่ที่คุณต้องการ (ทำให้ไฟล์ phar เรียกใช้งานได้ผ่าน chmod +x rmt.phar และดำเนินการโดยตรง ./rmt.phar หรือเรียกใช้โดยเรียกใช้ผ่าน PHP ผ่าน php rmt.phar
สำหรับการใช้งานแทน RMT กับตัวแปรใดก็ตามที่คุณตัดสินใจใช้
หากคุณใช้ https://github.com/liip/drifter สำหรับโครงการของคุณคุณแค่ต้องใช้สามขั้นตอน
เปิดใช้งานบทบาท rmt
เรียกใช้ vagrant provision อีกครั้ง
init rmt สำหรับโครงการของคุณ php /home/vagrant/.config/composer/vendor/liip/rmt/RMT
การใช้ RMT นั้นตรงไปตรงมามากเพียงเรียกใช้คำสั่ง:
./RMT release
RMT จะดำเนินงานต่อไปนี้:
ดำเนินการตรวจสอบข้อกำหนดเบื้องต้น
ขอให้ผู้ใช้ตอบคำถามที่มีศักยภาพ
ดำเนินการดำเนินการล่วงหน้า
ปล่อย
สร้างหมายเลขเวอร์ชันใหม่
คงอยู่หมายเลขเวอร์ชันใหม่
ดำเนินการโพสต์รีลีส
นี่คือตัวอย่างผลลัพธ์:
คำสั่ง release มีพฤติกรรมหลักของเครื่องมือเพิ่มเติมคำสั่งพิเศษเพิ่มเติมพร้อมใช้งาน:
current จะแสดงหมายเลขเวอร์ชันปัจจุบันของโครงการของคุณ (นามแฝงเวอร์ชัน)
changes แสดงการเปลี่ยนแปลงที่จะรวมอยู่ในรุ่นถัดไป
config แสดงการกำหนดค่าปัจจุบัน (รวมอยู่แล้ว)
init สร้าง (หรือรีเซ็ต) ไฟล์ config. rmt.yml
การกำหนดค่า RMT ทั้งหมดจะต้องทำใน. .rmt.yml ไฟล์ถูกแบ่งออกเป็นหกองค์ประกอบรูท:
vcs : ประเภทของ VCs ที่คุณใช้สามารถเป็น git , svn หรือ none
สำหรับ git VCS คุณสามารถใช้ตัวเลือกสองตัวต่อไปนี้ sign-tag และ sign-commit หากคุณต้องการใช้ GPG ลงนามในรุ่นของคุณ
prerequisites : รายการ [] ของข้อกำหนดเบื้องต้นที่ต้องจับคู่ก่อนเริ่มกระบวนการวางจำหน่าย
pre-release-actions : รายการ [] ของการกระทำที่จะดำเนินการก่อนกระบวนการปล่อย
version-generator : เครื่องกำเนิดไฟฟ้าที่จะใช้เพื่อสร้างเวอร์ชันใหม่ (บังคับ)
version-persister : Persister ที่จะใช้ในการจัดเก็บเวอร์ชัน (บังคับ)
post-release-actions : รายการ [] ของการกระทำที่จะดำเนินการหลังจากการเปิดตัว
รายการทั้งหมดของการกำหนดค่านี้ทำงานเหมือนกัน คุณต้องระบุคลาสที่คุณต้องการจัดการกับการกระทำ ตัวอย่าง:
version-generator: "simple"` version-persister: vcs-tag: tag-prefix: "v_"
RMT ยังรองรับการกำหนดค่า JSON แต่เราขอแนะนำให้ใช้ YAML
บางครั้งคุณต้องการใช้กลยุทธ์การเปิดตัวที่แตกต่างกันตามสาขา VCS เช่นคุณต้องการเพิ่มรายการ Changelog เฉพาะในสาขา master เท่านั้น ในการทำเช่นนั้นคุณต้องวางการกำหนดค่าเริ่มต้นของคุณลงในองค์ประกอบรูทชื่อ _default จากนั้นคุณสามารถแทนที่บางส่วนของการกำหนดค่าเริ่มต้นนี้สำหรับ master สาขา ตัวอย่าง:
_default: version-generator: "simple" version-persister: "vcs-tag" master: pre-release-actions: [changelog-update]
คุณสามารถใช้คำสั่ง RMT config เพื่อดูผลลัพธ์การผสานระหว่าง _default และสาขาปัจจุบันของคุณ
กลยุทธ์การสร้างหมายเลขรุ่น Build-in
ง่าย: เครื่องกำเนิดไฟฟ้านี้เพิ่มขึ้นอย่างง่าย (1,2,3 ... )
ความหมาย: เครื่องกำเนิดไฟฟ้าที่ใช้เวอร์ชันความหมาย
ตัวเลือกการบังคับสองตัวอาจมีประโยชน์มากหากคุณตัดสินใจว่าสาขาที่กำหนดจะทุ่มเทให้กับเบต้าถัดไปของเวอร์ชันที่กำหนด ดังนั้นเพียงแค่บังคับฉลากไปยังเบต้าและการเปิดตัวทั้งหมดจะเพิ่มขึ้นเบต้า
ตัวเลือก allow-label (บูลีน): เพื่ออนุญาตให้เพิ่มป้ายกำกับในเวอร์ชัน (เช่น -beta, -rcxx) (ค่าเริ่มต้น: false )
type ตัวเลือก: เพื่อบังคับประเภทเวอร์ชัน
label ตัวเลือก: เพื่อบังคับฉลาก
คลาสที่รับผิดชอบการบันทึก/ดึงหมายเลขเวอร์ชัน
VCS-TAG: บันทึกเวอร์ชันเป็นแท็ก VCS
ตัวเลือก tag-pattern : อนุญาตให้จัดเตรียม regex ที่แท็กทั้งหมดต้องตรงกัน สิ่งนี้อนุญาตให้ปล่อยรุ่น 1.xx ในสาขาเฉพาะและปล่อย 2.xx ในสาขาแยกต่างหาก
ตัวเลือก tag-prefix : อนุญาตให้นำหน้าแท็ก VCS ทั้งหมดด้วยสตริง คุณสามารถมีตัวเลขตัวเลข แต่แท็กการสร้างเช่น v_2.3.4 เป็นโบนัสคุณสามารถใช้ตัวยึดตำแหน่งเฉพาะ: {branch-name} ที่จะฉีดชื่อสาขาปัจจุบันโดยอัตโนมัติในแท็ก ดังนั้นใช้การสร้างแบบง่ายและ tag-prefix: "{branch-name}_" และมันจะสร้างแท็กเช่น featureXY_1 , featureXY_2 , ฯลฯ ...
Changelog: บันทึกเวอร์ชันในไฟล์ changelog
location ตัวเลือก: ชื่อไฟล์ changelog ตำแหน่ง (ค่าเริ่มต้น: changelog )
การกระทำที่จำเป็นต้องมีการดำเนินการก่อนส่วนการโต้ตอบ
working-copy-check : ตรวจสอบว่าคุณไม่มีการเปลี่ยนแปลงในท้องถิ่นของ VCS
ตัวเลือก allow-ignore --ignore-check
display-last-changes : แสดงการเปลี่ยนแปลงครั้งสุดท้ายของคุณ
tests-check : เรียกใช้ชุดทดสอบโครงการ
command ตัวเลือก: คำสั่งที่จะเรียกใช้ (ค่าเริ่มต้น: phpunit )
timeout ตัวเลือก: จำนวนวินาทีหลังจากนั้นคำสั่งหมดเวลา (ค่าเริ่มต้น: 60.0 )
ตัวเลือก expected_exit_code : รหัสส่งคืนที่คาดหวัง (ค่าเริ่มต้น: 0 )
composer-json-check : เรียกใช้การตรวจสอบความถูกต้องบนนักแต่งเพลง json
ตัวเลือก composer : วิธีเรียกใช้นักแต่งเพลง (ค่าเริ่มต้น: php composer.phar )
composer-stability-check : จะตรวจสอบว่านักแต่งเพลง json ถูกตั้งค่าเป็นเสถียรภาพขั้นต่ำที่เหมาะสม
ตัวเลือก stability : ความเสถียรที่ควรตั้งค่าในฟิลด์ความเสถียรขั้นต่ำ (ค่าเริ่มต้น: เสถียร )
composer-security-check : เรียกใช้ Composer.lock กับ https://github.com/fabpot/local-php-security-checker เพื่อตรวจสอบช่องโหว่ที่รู้จักในการพึ่งพา
ต้องติดตั้งไบนารีการตรวจสอบความปลอดภัยในท้องถิ่น-PHP-Security-Checker ทั่วโลก
composer-dependency-stability-check
ตัวเลือก ignore-require และ ignore-require-dev : อย่าตรวจสอบการพึ่งพาใน require หรือ require-dev
ตัวเลือก whitelist : อนุญาตให้พึ่งพาเฉพาะการใช้เวอร์ชันการพัฒนา
command : เรียกใช้คำสั่งระบบ
ตัวเลือก cmd คำสั่งเพื่อดำเนินการ
ตัวเลือก live_output Boolean เราแสดงเอาต์พุตคำสั่งหรือไม่? (ค่าเริ่มต้น: จริง )
ตัวเลือก timeout จำนวนเต็ม จำกัด เวลาสำหรับคำสั่ง (ค่าเริ่มต้น: 600 )
ตัวเลือก stop_on_error BOOLEAN เราทำลายกระบวนการเผยแพร่โดยใช้ข้อผิดพลาดหรือไม่? (ค่าเริ่มต้น: จริง )
การกระทำสามารถใช้สำหรับชิ้นส่วนก่อนหรือหลังการวางจำหน่าย
changelog-update : อัปเดตไฟล์ Changelog การดำเนินการนี้ได้รับการกำหนดค่าเพิ่มเติมให้ใช้รูปแบบเฉพาะ
format ตัวเลือก: ง่าย ความหมาย markdown หรือ addtop (ค่าเริ่มต้น: ง่าย )
file ตัวเลือก: พา ธ จาก. rmt.yml ไปยังไฟล์ changelog (ค่าเริ่มต้น: changelog )
ตัวเลือก dump-commits : เขียนข้อความทั้งหมดที่ส่งข้อความตั้งแต่รุ่นล่าสุดลงในไฟล์ changelog (ค่าเริ่มต้น: false )
ตัวเลือก insert-at : เฉพาะสำหรับ AddTop Formatter: จำนวนบรรทัดที่จะข้ามจากด้านบนของไฟล์ changelog ก่อนที่จะเพิ่มหมายเลขรีลีส (ค่าเริ่มต้น: 0 )
ตัวเลือก exclude-merge-commits : ไม่รวมการรวม Commits จาก Changelog (ค่าเริ่มต้น: FALSE )
vcs-commit : ส่งไฟล์ทั้งหมดของสำเนาที่ใช้งานได้ (ใช้กับข้อกำหนดเบื้องต้น working-copy-check
ตัวเลือก commit-message : ระบุข้อความการกระทำที่กำหนดเอง % เวอร์ชัน% จะถูกแทนที่ด้วยสตริงเวอร์ชันปัจจุบัน / ถัดไป
vcs-tag : แท็กการกระทำครั้งสุดท้าย
vcs-publish : เผยแพร่การเปลี่ยนแปลง (commits and tags)
composer-update : อัปเดตหมายเลขเวอร์ชันในไฟล์ Composer (โปรดทราบว่าเมื่อใช้ Packagist.org ขอแนะนำให้ไม่มีแท็กใน Composer.json เป็นรุ่นที่จัดการโดยแท็กควบคุมเวอร์ชัน)
files-update : อัปเดตเวอร์ชันในหนึ่งไฟล์หรือหลายไฟล์ สำหรับแต่ละไฟล์ที่จะอัปเดตโปรดระบุอาร์เรย์ด้วย
file ตัวเลือก: พา ธ ไปยังไฟล์เพื่ออัปเดต
pattern ตัวเลือก: ตัวเลือกใช้เพื่อระบุรูปแบบการแทนที่สตริงในไฟล์ของคุณ ตัวอย่างเช่น: const VERSION = '%version%';
build-phar-package : สร้างแพ็คเกจ phar ของโครงการปัจจุบันที่มีชื่อไฟล์ขึ้นอยู่กับตัวเลือก 'แพ็คเกจชื่อ' และเวอร์ชันที่ปรับใช้: [แพ็คเกจชื่อ]-[เวอร์ชัน] .phar
package-name ตัวเลือก: ชื่อของแพ็คเกจสร้าง
destination ตัวเลือก: ไดเรกทอรีปลายทางเพื่อสร้างแพ็คเกจลงใน หากนำหน้าด้วยสแลชถือเป็นสัมบูรณ์มิฉะนั้นจะสัมพันธ์กับรูทโครงการ
ตัวเลือก excluded-paths : regex ของเส้นทางที่ถูกกีดกันส่งผ่านโดยตรงไปยังวิธีการ phar :: buildfromdirectory Ex: /^(?!.*cookbooks|.*.vagrant|.*.idea).*$/im
ตัวเลือก metadata : อาร์เรย์ของข้อมูลเมตาที่อธิบายถึงแพ็คเกจ อดีตผู้เขียนโครงการ หมายเหตุ: รุ่นรีลีสถูกเพิ่มโดยค่าเริ่มต้น แต่สามารถแทนที่ได้ที่นี่
ตัวเลือก default-stub-cli : ต้นขั้วเริ่มต้นสำหรับการใช้งาน CLI ของแพ็คเกจ
ตัวเลือก default-stub-web : ต้นขั้วเริ่มต้นสำหรับการใช้งานเว็บแอปพลิเคชันของแพ็คเกจ
command : เรียกใช้คำสั่งระบบ
ตัวเลือก cmd คำสั่งเพื่อดำเนินการ
ตัวเลือก live_output Boolean เราแสดงเอาต์พุตคำสั่งหรือไม่? (ค่าเริ่มต้น: จริง )
ตัวเลือก timeout จำนวนเต็ม จำกัด เวลาสำหรับคำสั่ง (ค่าเริ่มต้น: 600 )
ตัวเลือก stop_on_error BOOLEAN เราทำลายกระบวนการเผยแพร่โดยใช้ข้อผิดพลาดหรือไม่? (ค่าเริ่มต้น: จริง )
update-version-class : อัปเดตเวอร์ชันค่าคงที่ในไฟล์คลาส เลิกใช้ files-update แทน
class ตัวเลือก: พา ธ ไปเรียนที่จะอัปเดตหรือชื่อคลาสที่ผ่านการรับรองอย่างสมบูรณ์ของคลาสที่มีค่าคงที่เวอร์ชัน
pattern ตัวเลือก: ตัวเลือกใช้เพื่อระบุรูปแบบการเปลี่ยนสตริงในคลาสเวอร์ชันของคุณ % เวอร์ชัน% จะถูกแทนที่ด้วยสตริงเวอร์ชันปัจจุบัน / ถัดไป ตัวอย่างเช่นคุณสามารถใช้ const VERSION = '%version%'; - หากคุณไม่ได้ระบุตัวเลือกนี้การเกิดขึ้นของสตริงเวอร์ชันในไฟล์จะถูกแทนที่ทุกครั้ง
RMT กำลังให้การกระทำที่มีอยู่เครื่องกำเนิดไฟฟ้าและการคงอยู่ หากจำเป็นคุณสามารถเพิ่มของคุณเองได้โดยการสร้างสคริปต์ PHP ในโครงการของคุณและอ้างอิงในการกำหนดค่าผ่านเส้นทางสัมพัทธ์:
version-generator: "bin/myOwnGenerator.php"
ตัวอย่างด้วยพารามิเตอร์ที่ฉีด:
version-persister: name: "bin/myOwnGenerator.php" parameter1: value1
ตัวอย่างเช่นคุณสามารถดูสคริปต์ /bin/updateapplicationversioncurrentversion.php ที่กำหนดค่าไว้ที่นี่
คำเตือน: เนื่องจาก name คีย์ถูกใช้เพื่อกำหนดชื่อของวัตถุคุณจะไม่สามารถมี name พารามิเตอร์ชื่อได้
ส่วนใหญ่เวลาจะง่ายกว่าสำหรับคุณที่จะรับตัวอย่างด้านล่างและปรับให้เข้ากับความต้องการของคุณ
version-generator: semantic version-persister: changelog
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: simple version-persister: vcs-tag prerequisites: - composer-json-check - composer-stability-check: stability: beta - composer-dependency-stability-check: whitelist: - [symfony/console] - [phpunit/phpunit, require-dev]
vcs: name: git sign-tag: true sign-commit: true version-generator: simple version-persister: vcs-tag prerequisites: [working-copy-check, display-last-changes]
vcs: git version-generator: semantic version-persister: name: vcs-tag tag-prefix : "v_" pre-release-actions: files-update: - [config.yml] - [app.ini, 'dynamic-version: %version%'] post-release-actions: [vcs-publish]
_default:
vcs: git
prerequisites: [working-copy-check]
version-generator: simple
version-persister:
name: vcs-tag
tag-prefix: "{branch-name}_"
post-release-actions: [vcs-publish]
# This entry allow to override some parameters for the master branch
master:
prerequisites: [working-copy-check, display-last-changes]
pre-release-actions:
changelog-update:
format: markdown
file: CHANGELOG.md
dump-commits: true
update-version-class:
class: DoctrineODMPHPCRVersion
pattern: const VERSION = '%version%';
vcs-commit: ~
version-generator: semantic
version-persister: vcs-tagหากคุณต้องการความช่วยเหลือโดยส่งสคริปต์แอ็คชั่นเครื่องกำเนิดไฟฟ้าหรือการแสดงความคิดเห็นของคุณ หรือเพียงแค่รายงานข้อผิดพลาดเพียงไปที่หน้าโครงการ https://github.com/liip/rmt
หากคุณให้การประชาสัมพันธ์ให้ลองเชื่อมโยงหน่วยหรือการทดสอบการทำงาน ดูส่วนถัดไป
เพื่อให้สามารถเรียกใช้การทดสอบในพื้นที่คุณต้องการ:
phpunit
กระตวน
ปรุงรส
คุณสามารถติดตั้งทั้งหมดด้วย Brew:
> brew install phpunit git hg
การทดสอบยังทดสอบการสร้าง RMT Phar ดังนั้นคุณต้องอนุญาตสิ่งนี้ใน php.ini ของคุณโดยการเขียนบทนี้:
phar.readonly = Off
ในที่สุดในการเรียกใช้การทดสอบเพียงแค่เปิดตัว phpunit
> phpunit
การทดสอบการทำงานเป็นการตั้งค่า RMT ชั่วคราวอย่างสมบูรณ์ ทุกครั้งที่คุณทำการทดสอบการทำงานจะสร้างโฟลเดอร์ชั่วคราวด้วยโครงการ RMT จากนั้นชุดทดสอบจะเรียกใช้คำสั่ง RMT และตรวจสอบผลลัพธ์ นั่นเป็นเหตุผลที่คุณต้องติดตั้ง Git และ Mercurial
ในการดีบักการทดสอบการทำงานของ RMT สิ่งที่ดีที่สุดคือเข้าไปในโฟลเดอร์ชั่วคราวนี้และสำรวจโครงการด้วยตนเอง ในการทำเช่นนั้นเพียงเพิ่ม $this->manualDebug(); เข้าไปในชุดทดสอบ สิ่งนี้จะทำลายการทดสอบด้วยผลลัพธ์ต่อไปนี้:
MANUAL DEBUG Go to: > cd /private/var/folders/hl/gnj5dcj55gbc93pcgrjxbb0w0000gn/T/ceN2Mf
จากนั้นคุณต้องเข้าไปในโฟลเดอร์ดังกล่าวและเริ่มการดีบัก
Jonathan Macheret, Liip SA
David Jeanmonod Liip Sa
และผู้มีส่วนร่วมอื่น ๆ
RMT ได้รับใบอนุญาตภายใต้ใบอนุญาต MIT ดูไฟล์ใบอนุญาตสำหรับรายละเอียด
