Хувилбар удирдах системийн зөв хэрэглээ У.Оргил

orgil.u@gmail.com

Өнөөдрийн яриагаар хувилбар удирдах системийн коммандууд, давуу талуудын талаар ярихгүй.

Энэ талаар мэдэхийг хүсвэл Хасчулуугийн Git and Github яриаг үзээрэй. Мөн

http://progit.org болон бусад цахим хуудаснаас дэлгэрэнгүй мэдээллийг авч болно.

Юу ярилцах вэ? • Төслийн код, шинж чанар

• Хувилбар удирдах систем

• Системийн зөв хэрэглээний үр дүн

• Commit хэрхэн зөв хийх вэ

• Мөчир хэдийд үүсгэх вэ

• Мөчир нэгтгэх(merge), давхцал (conflict)

• Хувийн агуулах(repository)-ын зохион байгуулалт

• Багийн агуулахын зохион байгуулалтууд • Удирдагчтай агуулахын загвар – Github workflow

• Хувилбар үүсгэх болон тэмдэглэгээ хийх • Түгээмэл нэршил

• Semantic Version numbering

• Асуулт, Хариулт

Төслийн кодын шинж чанар

• Аливаа төслийн код нь багийн бүтээл

• Байнга өөрчлөгдөж байдаг

• Өөрчлөлт болгон дээр алдаа гарах магадлал өндөр

• Зохион байгуулалтын хувьд хийсвэр байдаг учраас байнгын хяналт шаардагддаг

• Хэрэгжүүлэлтээс хэрэглэгч хүртэл маш олон шат дамжлагатай

• Төсөл амжилттай хэрэгжихийн тулд маш олон асуудлыг нэг дор шийдэх шаардлагатай

Төслийн бүрэлдэхүүн

Хувилбар удирдах систем гэдэг нь товчхондоо төслийн файлын өөрчлөлтийг хянаж өөрчлөлт бүрт дээрх асуудлуудыг шийдвэрлэхэд тусладаг хэрэгсэлүүдийн нэг юм.

Хувилбар удирдах системийг хэрэглэлгүйгээр дээрх асуудлыг тогтвортой шийдвэрлэх боломжгүй.

Системийн зөв хэрэглээний үр дүн • Хувилбарын оновчтой шийдэл

• Roadmap болон төлөвлөгөөний дагуу ажиллах

• Эмх цэгцтэй Changelog үүсгэх

• Багийн гишүүдийн зэрэгцээ ажиллагааны боломж

• Бичсэн кодоо бусдад нээлттэй байлгах • API функцуудын зохицуулалт

• Уян хатан, ойлгомжтой байдал

• Хөгжүүлэгчид хоорондын зөв ойлголцол

• Хуучин хувилбаруудыг дэмжиж ажиллах гэх мэт

• Гарсан алдааг эмх цэгцтэй засварлах

• Хэрэглэгчдээ найдвартай кодоор хангах • Нууцлал

• Алдаагүй ажиллагаа

Commit – ямар байх вэ Нэгж бүтэцтэй байхаас гадна дараах асуултанд хариуж байх хэрэгтэй

• Хэн?

• Хэзээ?

• Хаана? *

• Юуг?

• Яагаад?

Эхний гурван асуултанд commit хийх үед Git хариулна. Гэхдээ хаана гэдэг асуудлыг тодорхой оруулж байх хэрэгтэй.

Сүүлийн гурван асуултанд товч тодорхой тайлбар хийх хэрэгтэй.

Commit – түгээмэл алдаа

- Тайлбар хийхдээ хэтэрхий ерөнхий тайлбаруудыг хийдэг.

Жишээ нь: засвар хийлээ, шинээр файл нэмлээ, админ хэсгийн хуучин алдааг заслаа гэх мэт.

- Маш олон зүйлийг нэгтгэж нэг commit хийх

- Статик өгөгдлүүдийг багтаах

- Тохиргооны файлуудыг нэгтгэх

- Өгөгдлийн сангийн өөрчлөлтийг орхигдуулдаг

- Гуравдагч сан, компонентууд, framework-уудыг нэгтгэх

Мөчир – хэдийд үүсгэх вэ

• Шинэ боломж бүрт (Use case, story, feature) болгонд

• Туршилт болон шинэ технологи нэвтрүүлэх үед

• Алдаа засах үед

• Release гаргах үед

• Хуучин хувилбарт засвар хийх үед /legacy support/

Ганцаараа ажиллаж байгаа учираас мөчир үүсгэх шаардлагагүй гэсэн буруу ойлголт байдаг.

Мөчир нэгтгэх • Давхцалуудыг сайтар хянах

• Тухайн мөчирийг үүсгэсэн зорилго биелэсэн үед үндсэн мөчирт нэгтгэж байх

Хувийн агуулахын загвар Vincent Driessen - http://bit.ly/9bUvdE

Багийн агуулахын загварууд

• Centralized Shared Repository

• Integration manager

• Dictator and Lieutenants

Centralized Shared Repository

Integration Manager - Github

Dictator and Lieutenants

Github

• Хөгжүүлэгч найдвартай агуулахаас өөрийн нээлттэй агуулах уруу кодыг хуулна. (fork)

• Өөрийн нээлттэй агуулахаас хаалттай агуулах уруу кодыг хуулна. (pull)

• Засвар болон хөгжүүлэлтийг хийнэ.

• Өөрчлөлтийг өөрийн хаалтай агуулахад хадгална. (commit)

• Хаалттай агуулахаас нээлттэй агуулах уруу хадгална. (push)

• Төслийн удирдагчид өөрчлөлтийг мэдэгдэнэ. (pull request)

• Төслийн удирдагч өөрчлөлтийг хянаад үндсэн мөчирт нэгтгэнэ.

Удирдагчтай агуулахын загвар

Хувилбарийн түгээмэл нэршил • Build

• Unit test, compile

• Alpha

• Цаашид шинэ боломж нэмэгдэнэ

• Үндсэн функц, public API өөрчлөгдөх магадлалтай

• Beta

• Нийтэд танилцуулж алдаа засах

• Үндсэн функц, public API өөрчлөгдөх магадлалтай

• Release candidate

• Зөвхөн алдаа засвар хийгдэнэ

• Public API - freeze

• Stable release

• Эцсийн тогтвортой хувилбар

Semantic Version numbering

• Github үүсгэн байгуулагчдын нэг, Gravatar-ыг үүсгэгч Tom Preston Werner боловсруулсан

• Эхний орон major хувилбар

• 2 дахь орон minor хувилбар

• 3 дахь орон patch хувилбар

• Pre-release нэршил

• Түүний хувилбар

http://semver.org хаягаас дэлгэрэнгүй дүрэмтэй танилцаарай

1.2.5-rc-1

Дараагийн яриагаар

Автоматжуулалт

Continuous Integration

Анхаарал тавьсанд баярлалаа

Асуулт ?