ယနေ့ခေတ်တွင် ဆော့ဖ်ဝဲလ်ထုတ်ကုန်အများစုကို အဖွဲ့များဖြင့် တီထွင်ကြသည်။ အောင်မြင်သောအဖွဲ့ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် အခြေအနေများကို ရိုးရှင်းသော ပုံသေပုံစံဖြင့် ကိုယ်စားပြုနိုင်ပါသည်။

သင့်ကုဒ်ကို ရေးပြီးသည်နှင့် သေချာအောင် ပြုလုပ်ရန် လိုအပ်သည်-

1. Работает။
2. မင်းလုပ်ဖော်ကိုင်ဖက်တွေ ရေးတဲ့ကုဒ်တွေ အပါအဝင် ဘာမှ ပျက်မသွားပါဘူး။

အခြေ အနေ နှစ်ခု လုံး ပြည့် စုံ ပါ က သင် အောင်မြင် မှု လမ်းကြောင်း ပေါ် ရောက် နေပြီ ။ ဤအခြေအနေများကို အလွယ်တကူစစ်ဆေးရန်နှင့် အမြတ်အစွန်းရှိသောလမ်းကြောင်းမှ သွေဖည်မသွားစေရန်၊ ကျွန်ုပ်တို့သည် စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုကို တီထွင်ခဲ့ပါသည်။

CI သည် သင့်ကုဒ်ကို ထုတ်ကုန်ကုဒ်အဖြစ် တတ်နိုင်သမျှ အလုံးစုံ ပေါင်းစပ်ထည့်သွင်းသည့် အလုပ်အသွားအလာတစ်ခုဖြစ်သည်။ ပေါင်းစည်းရုံမျှမကဘဲ အရာအားလုံးအလုပ်လုပ်နေကြောင်းကိုလည်း အမြဲစစ်ဆေးပါ။ အများကြီးနဲ့ မကြာခဏ စစ်ဆေးဖို့ လိုအပ်တာကြောင့်၊ အလိုအလျောက်စနစ်နဲ့ ပတ်သက်ပြီး စဉ်းစားသင့်တယ်။ အရာအားလုံးကို သင်ကိုယ်တိုင်စစ်ဆေးနိုင်သော်လည်း သင်မဖြစ်သင့်ပါ၊ ဤသည်မှာ အဘယ်ကြောင့်နည်း။

• ချစ်လှစွာသောလူ. မည်သည့်ပရိုဂရမ်မာတစ်ဦး၏အလုပ်ချိန်တစ်နာရီသည်မည်သည့်ဆာဗာ၏အလုပ်တစ်နာရီထက်ပိုမိုစျေးကြီးသည်။
• လူတွေက အမှားလုပ်တယ်။. ထို့ကြောင့်၊ စာမေးပွဲများကို မှားယွင်းသောဌာနခွဲတွင် လုပ်ဆောင်သည့်အခါ သို့မဟုတ် စမ်းသပ်သူများအတွက် မှားယွင်းသော ကွန်မန့်ကို စုစည်းထားသည့်အခါ အခြေအနေများ ဖြစ်ပေါ်လာနိုင်သည်။
• လူတွေက ပျင်းတယ်။. အလုပ်တစ်ခုပြီးမြောက်တဲ့အခါ ရံဖန်ရံခါမှာ “စစ်ဆေးဖို့ ဘာရှိလဲ? ကျွန်တော် စာကြောင်းနှစ်ကြောင်းရေးခဲ့တယ် - အရာအားလုံး အဆင်ပြေပါတယ်။ တစ်ချို့ကျတော့လည်း တစ်ခါတလေ အဲဒီလို အတွေးတွေ ရှိတယ်။ ဒါပေမယ့် အမြဲတမ်း စစ်ဆေးသင့်ပါတယ်။

Avito မိုဘိုင်းဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့တွင် စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုကို အကောင်အထည်ဖော်ပုံ၊ ၎င်းတို့သည် တစ်နေ့လျှင် 0 မှ 450 အတွင်း တည်ဆောက်ပုံ၊ စက်တည်ဆောက်ပုံသည် တစ်နေ့လျှင် နာရီ 200 တပ်ဆင်ကြောင်း Nikolai Nesterov (nnesterov) သည် CI/CD Android အပလီကေးရှင်း၏ ဆင့်ကဲပြောင်းလဲမှုအားလုံးတွင် ပါဝင်သူဖြစ်သည်။

ဇာတ်လမ်းသည် Android command ၏နမူနာကို အခြေခံထားသော်လည်း ချဉ်းကပ်မှုအများစုကို iOS တွင်လည်း အသုံးပြုနိုင်သည်။

တစ်ချိန်က လူတစ်ဦးသည် Avito Android အဖွဲ့တွင် အလုပ်လုပ်ခဲ့သည်။ အဓိပ္ပါယ်အားဖြင့်၊ သူသည် Continuous Integration မှ မည်သည့်အရာကိုမျှ မလိုအပ်ပါ၊ ပေါင်းစည်းရန် မည်သူမျှ မရှိပါ။

သို့သော် လျှောက်လွှာသည် တိုးလာသည်၊ အလုပ်သစ်များ ပိုများလာသည်နှင့်အမျှ အဖွဲ့သည် တိုးတက်လာသည်။ တစ်ချိန်ချိန်တွင်၊ ကုဒ်ပေါင်းစည်းမှု လုပ်ငန်းစဉ်ကို ပိုမိုတရားဝင်လုပ်ဆောင်ရန် အချိန်ကျရောက်လာပြီဖြစ်သည်။ Git flow ကိုအသုံးပြုရန်ဆုံးဖြတ်ခဲ့သည်။

Git flow ၏ သဘောတရားကို လူသိများသည်- ပရောဂျက်တစ်ခုတွင် ဘုံဖွံ့ဖြိုးတိုးတက်ရေးဌာနခွဲတစ်ခုပါရှိပြီး အင်္ဂါရပ်အသစ်တစ်ခုစီအတွက် developer များသည် သီးခြားအကိုင်းအခက်တစ်ခုကို ဖြတ်တောက်ကာ ၎င်းကို ကုဒ်လုပ်ရန်၊ တွန်းအားပေးကာ ၎င်းတို့၏ကုဒ်ကို ဖွံ့ဖြိုးတိုးတက်ရေးဌာနခွဲသို့ ပေါင်းစည်းလိုသောအခါတွင် ဖွင့်ပါ။ တောင်းဆိုချက်ဆွဲ။ အသိပညာမျှဝေခြင်းနှင့် ချဉ်းကပ်နည်းများကို ဆွေးနွေးရန်၊ ကျွန်ုပ်တို့သည် ကုဒ်ပြန်လည်သုံးသပ်ခြင်းကို မိတ်ဆက်ပေးခဲ့သည်၊ ဆိုလိုသည်မှာ လုပ်ဖော်ကိုင်ဖက်များသည် အချင်းချင်း၏ကုဒ်ကို စစ်ဆေးပြီး အတည်ပြုရပါမည်။

စစ်ဆေးမှုများ

ကုဒ်ကို မျက်လုံးဖြင့်ကြည့်ခြင်းသည် အေးချမ်းသော်လည်း မလုံလောက်ပါ။ ထို့ကြောင့် အလိုအလျောက် စစ်ဆေးမှုများကို စတင်လုပ်ဆောင်နေပါသည်။

• ပထမဆုံးအနေနဲ့ ကျွန်တော်တို့ စစ်ဆေးပါတယ်။ ARK ပရိသတ်.
• အများကြီး Junit စာမေးပွဲများ.
• ကျွန်ုပ်တို့သည် ကုဒ်လွှမ်းခြုံမှုကို ထည့်သွင်းစဉ်းစားသည်။ကျွန်ုပ်တို့သည် စမ်းသပ်မှုများ လုပ်ဆောင်နေသောကြောင့်ဖြစ်သည်။

ဤစစ်ဆေးမှုများကို မည်သို့လုပ်ဆောင်ရမည်ကို နားလည်ရန်၊ Avito ရှိ ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်ကို ကြည့်ကြပါစို့။

ဤကဲ့သို့ ဇယားကွက်ဖြင့် ကိုယ်စားပြုနိုင်သည်-

• ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ယောက်က သူ့လက်တော့ပ်မှာ ကုဒ်ရေးတယ်။ ပေါင်းစပ်စစ်ဆေးမှုများကို ဤနေရာတွင် လုပ်ဆောင်နိုင်သည် - commit ချိတ်ဖြင့်ဖြစ်စေ သို့မဟုတ် နောက်ခံတွင် စစ်ဆေးမှုများကို ရိုးရိုးရှင်းရှင်း လုပ်ဆောင်နိုင်သည်။
• ဆော့ဖ်ဝဲရေးသားသူက ကုဒ်ကို တွန်းထုတ်ပြီးနောက်၊ ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ဖွင့်သည်။ ၎င်း၏ကုဒ်ကို ဖွံ့ဖြိုးတိုးတက်ရေးဌာနခွဲတွင် ထည့်သွင်းရန်အတွက်၊ ကုဒ်ပြန်လည်သုံးသပ်မှုတစ်ခုပြုလုပ်ပြီး လိုအပ်သောအတည်ပြုချက်အရေအတွက်ကို စုဆောင်းရန် လိုအပ်ပါသည်။ စစ်ဆေးမှုများနှင့် တည်ဆောက်မှုများကို ဤနေရာတွင် သင်ဖွင့်နိုင်သည်- တည်ဆောက်မှုအားလုံး အောင်မြင်သည်အထိ ဆွဲယူတောင်းဆိုမှုကို ပေါင်းစည်း၍မရပါ။
• ဆွဲယူတောင်းဆိုမှုကို ပေါင်းစည်းပြီး develop တွင် ကုဒ်ထည့်သွင်းပြီးနောက်၊ အဆင်ပြေသည့်အချိန်ကို သင်ရွေးချယ်နိုင်သည်- ဥပမာ၊ ညအချိန်တွင်၊ ဆာဗာများအားလုံး အခမဲ့ဖြစ်ပြီး သင်နှစ်သက်သလောက် စစ်ဆေးမှုများကို လုပ်ဆောင်ပါ။

၎င်းတို့၏လက်ပ်တော့ပေါ်တွင် စကင်န်ဖတ်ခြင်းကို မည်သူမျှ မကြိုက်ပါ။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် အင်္ဂါရပ်တစ်ခုကို ပြီးမြောက်သောအခါ၊ ၎င်းက ၎င်းကို အမြန်တွန်းတင်ပြီး ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ဖွင့်လိုသည်။ ဤအခိုက်အတန့်တွင် ရှည်လျားသောစစ်ဆေးမှုအချို့ကို စတင်လုပ်ဆောင်ပါက၊ ၎င်းသည် အလွန်သာယာရုံသာမက ဖွံ့ဖြိုးတိုးတက်မှုကိုလည်း နှေးကွေးစေသည်- လက်ပ်တော့သည် တစ်ခုခုကို စစ်ဆေးနေချိန်တွင် ၎င်းကို ပုံမှန်အတိုင်းလုပ်ဆောင်ရန် မဖြစ်နိုင်ပါ။

အချိန်နှင့်ဆာဗာများ များစွာရှိသောကြောင့် ညဘက်တွင် စစ်ဆေးမှုများ လုပ်ဆောင်ခြင်းကို ကျွန်ုပ်တို့ အလွန်နှစ်သက်ပါသည်။ သို့သော် ကံမကောင်းစွာပဲ၊ အင်္ဂါရပ်ကုဒ်ကို ဖွံ့ဖြိုးလာသောအခါ၊ developer သည် CI တွေ့ရှိခဲ့သော အမှားများကို ပြင်ဆင်ရန် လှုံ့ဆော်မှု နည်းပါးသွားပါသည်။ မနက်ခင်းမှာ တွေ့ရတဲ့ အမှားအယွင်းတွေအားလုံးကို ကြည့်ပြီး တစ်နေ့နေ့ တစ်ချိန်ချိန်မှာ ပြင်ပေးပါ့မယ်လို့ တွေးနေမိတယ်၊ ခုတော့ Jira မှာ အရမ်းမိုက်တဲ့ အလုပ်အသစ်တစ်ခု ရှိနေပြီဆိုတော့ ခုမှ စလုပ်ချင်တာ။

စစ်ဆေးမှုတစ်ခုအား ဆွဲထုတ်ခြင်းအား ပိတ်ဆို့ပါက၊ တည်ဆောက်မှုများ စိမ်းလန်းလာသည်အထိ ကုဒ်သည် ဖွံ့ဖြိုးလာမည်မဟုတ်သောကြောင့်၊ ဆိုလိုသည်မှာ အလုပ်ပြီးမြောက်မည်မဟုတ်ပါ။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါဗျူဟာကို ရွေးချယ်ခဲ့သည်- ကျွန်ုပ်တို့သည် ညအချိန်တွင် ဖြစ်နိုင်ချေရှိသော စစ်ဆေးမှုများကို အများဆုံးလုပ်ဆောင်ပြီး ၎င်းတို့အနက်မှ အဝေဖန်အခံရဆုံးနှင့် အရေးအကြီးဆုံးမှာ၊ ဆွဲတင်တောင်းဆိုမှုတစ်ခုအတွက် အမြန်ဆုံးလုပ်ဆောင်ပေးပါသည်။ သို့သော် ကျွန်ုပ်တို့သည် ထိုနေရာတွင် ရပ်မနေပါ—တပြိုင်တည်းတွင်၊ တောင်းဆိုချက်များအား ထုတ်ယူရန်အတွက် ညမုဒ်မှ ၎င်းတို့ကို လွှဲပြောင်းရန်အတွက် စစ်ဆေးမှုများ၏ အမြန်နှုန်းကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ပါသည်။

ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့၏တည်ဆောက်မှုများအားလုံးသည် အလွန်လျင်မြန်စွာပြီးစီးသွားသောကြောင့် ARK တည်ဆောက်မှု၊ Junit စမ်းသပ်မှုများနှင့် ကုဒ်အကျုံးဝင်မှုတွက်ချက်မှုများကို ပိတ်ဆို့ခြင်းအဖြစ် ကျွန်ုပ်တို့တွင် ထည့်သွင်းထားသည်။ ကျွန်ုပ်တို့သည် ၎င်းကိုဖွင့်ထားပြီး၊ ၎င်းကိုစဉ်းစားကာ ၎င်းကိုမလိုအပ်ဟု ကျွန်ုပ်တို့ထင်သောကြောင့် ကုဒ်လွှမ်းခြုံမှုကို စွန့်လွှတ်ခဲ့သည်။

အခြေခံ CI ကို အပြီးအပိုင် သတ်မှတ်ရန် ကျွန်ုပ်တို့ နှစ်ရက် အချိန်ယူခဲ့ရသည် (ယခုအချိန် ခန့်မှန်းချက်သည် အနီးစပ်ဆုံးဖြစ်ပြီး အတိုင်းအတာအတွက် လိုအပ်သည်)။

ထို့နောက်တွင်၊ ကျွန်ုပ်တို့သည် ထပ်လောင်းတွေးတောမိတော့သည်၊ ကျွန်ုပ်တို့သည် မှန်မှန်ကန်ကန် စစ်ဆေးနေသလော။ ကျွန်ုပ်တို့သည် ဆွဲယူတောင်းဆိုမှုများတွင် တည်ဆောက်မှုများကို မှန်ကန်စွာ လုပ်ဆောင်နေပါသလား။

ဆွဲထုတ်တောင်းဆိုမှုကို ဖွင့်လှစ်ခဲ့သည့် နောက်ဆုံးဌာနခွဲ၏ နောက်ဆုံးကတိကဝတ်တွင် ကျွန်ုပ်တို့ စတင်တည်ဆောက်ခဲ့သည်။ သို့သော် ဤကွန်မန့်၏စမ်းသပ်မှုများသည် developer ရေးသောကုဒ်အလုပ်လုပ်သည်ကိုသာပြသနိုင်သည်။ ဒါပေမယ့် သူဘာမှ မကွဲဘူးဆိုတာ သက်သေမပြပါဘူး။ အမှန်မှာ၊ အင်္ဂါရပ်တစ်ခုသို့ ပေါင်းစည်းပြီးနောက် ဖွံ့ဖြိုးတိုးတက်မှုဌာနခွဲ၏ အခြေအနေကို စစ်ဆေးရန် လိုအပ်သည်။

ဒါကိုလုပ်ဖို့၊ ရိုးရှင်းတဲ့ bash script ကိုရေးခဲ့တယ်။ premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

ဤနေရာတွင် ဖွံ့ဖြိုးတိုးတက်မှုမှ နောက်ဆုံးပြောင်းလဲမှုအားလုံးကို ရိုးရှင်းစွာ ဆွဲထုတ်ပြီး လက်ရှိဌာနခွဲသို့ ပေါင်းစည်းလိုက်ပါသည်။ ကျွန်ုပ်တို့သည် တည်ဆောက်မှုအားလုံးတွင် ပထမအဆင့်အနေဖြင့် premerge.sh script ကိုထည့်သွင်းပြီး ကျွန်ုပ်တို့လိုချင်သည့်အရာကို အတိအကျစစ်ဆေးခြင်းဖြစ်သည်၊ ဆိုလိုသည်မှာ၊ ပေါင်းစည်းမှု.

ပြဿနာကို ဒေသစံသတ်မှတ်ရန်၊ အဖြေရှာရန်နှင့် ဤဇာတ်ညွှန်းရေးရန် သုံးရက်ကြာသည်။

အက်ပလီကေးရှင်းကို တီထွင်လိုက်သည်၊ အလုပ်များ ပိုများလာသည်၊ အဖွဲ့သည် ကြီးထွားလာပြီး premerge.sh သည် တစ်ခါတစ်ရံတွင် ကျွန်ုပ်တို့အား စွန့်လွတ်စပြုလာသည်။ Develop သည် တည်ဆောက်မှုကို ပျက်ပြားစေသော ကွဲလွဲသောပြောင်းလဲမှုများ ရှိခဲ့သည်။

ဤအရာဖြစ်ပျက်ပုံဥပမာ

ဆော့ဖ်ဝဲရေးသားသူ နှစ်ဦးသည် အင်္ဂါရပ် A နှင့် B တွင် တစ်ပြိုင်နက် စတင်လုပ်ဆောင်နေပါသည်။ အင်္ဂါရပ် A ၏ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ပရောဂျက်တွင် အသုံးမပြုသော အင်္ဂါရပ်တစ်ခုကို ရှာဖွေတွေ့ရှိသည် answer() ကင်းထောက်ကောင်းတစ်ယောက်ကဲ့သို့ ၎င်းကို ဖယ်ရှားသည်။ တစ်ချိန်တည်းမှာပင်၊ feature B ၏ developer သည် ၎င်း၏ဌာနခွဲရှိ ဤလုပ်ဆောင်ချက်အတွက် ခေါ်ဆိုမှုအသစ်တစ်ခုကို ပေါင်းထည့်သည်။

ဆော့ဖ်ဝဲရေးသားသူများသည် ၎င်းတို့၏လုပ်ငန်းကို အပြီးသတ်ပြီး တစ်ချိန်တည်းတွင် တောင်းဆိုချက်တစ်ခုကို ဖွင့်ပါ။ တည်ဆောက်မှုများကို စတင်လိုက်ပါပြီ၊ premerge.sh သည် နောက်ဆုံးပေါ် ဖွံ့ဖြိုးတိုးတက်မှုအခြေအနေနှင့် ပတ်သက်သည့် ဆွဲထုတ်တောင်းဆိုမှုများကို စစ်ဆေးပေးသည် - စစ်ဆေးမှုအားလုံးသည် အစိမ်းရောင်ဖြစ်သည်။ ထို့နောက်တွင်၊ feature A ၏ဆွဲအားတောင်းဆိုမှုကိုပေါင်းစည်းသည်၊ အင်္ဂါရပ် B ၏ဆွဲအားတောင်းဆိုမှုကိုပေါင်းစည်းသည်... Boom! ဖွံ့ဖြိုးဆဲကုဒ်တွင် တည်ရှိခြင်းမရှိသော လုပ်ဆောင်ချက်တစ်ခုသို့ ခေါ်ဆိုမှုတစ်ခုပါ၀င်သောကြောင့် တီထွင်လိုက်ခြင်းဖြစ်ပါသည်။

မဖွံ့ဖြိုးသေးတဲ့အခါ၊ ဒေသတွင်းဘေးအန္တရာယ်. အဖွဲ့တစ်ဖွဲ့လုံးသည် မည်သည့်အရာကိုမျှ စုဆောင်း၍ စမ်းသပ်ရန်အတွက် တင်ပြခြင်းမပြုနိုင်ပါ။

ခွဲခြမ်းစိတ်ဖြာမှု၊ ကွန်ရက်၊ ဒေတာဘေ့စ်များ၊ ဆိုလိုသည်မှာ၊ အခြား developer များအသုံးပြုသော ထို function နှင့် classes များကို ရေးသားခဲ့သူဖြစ်သည်။ ဒီအတွက်ကြောင့်လည်း အလားတူ အခြေအနေမျိုးမှာ မကြာခဏ တွေ့ခဲ့ရတယ်။ ဒီပုံလေးတောင် ခဏကြာအောင် ဆွဲထားလိုက်သေးတယ်။

၎င်းသည် ကျွန်ုပ်တို့နှင့် မကိုက်ညီသောကြောင့်၊ ၎င်းကို ကာကွယ်ရန် နည်းလမ်းများကို စတင်ရှာဖွေခဲ့သည်။

မဖွံဖြိုးအောင် ဘယ်လိုလုပ်မလဲ။

ပထမ option: develop ကိုမွမ်းမံသည့်အခါဆွဲယူတောင်းဆိုမှုများအားလုံးကိုပြန်လည်တည်ဆောက်ပါ။ ကျွန်ုပ်တို့၏ဥပမာတွင်၊ feature A ပါသော ဆွဲထုတ်မှုတောင်းဆိုမှုသည် develop တွင်ပထမဆုံးထည့်သွင်းရန်ဖြစ်ပါက၊ လုပ်ဆောင်ချက် B ၏ဆွဲအားတောင်းဆိုမှုကို ပြန်လည်တည်ဆောက်မည်ဖြစ်ပြီး၊ ထို့ကြောင့်၊ စုစည်းမှုအမှားတစ်ခုကြောင့် စစ်ဆေးမှုများပျက်ကွက်မည်ဖြစ်သည်။

၎င်းသည်မည်မျှကြာမည်ကိုနားလည်ရန် PR နှစ်ခုပါသော ဥပမာတစ်ခုကို သုံးသပ်ကြည့်ပါ။ ကျွန်ုပ်တို့သည် PR နှစ်ခုကိုဖွင့်သည်- တည်ဆောက်မှုနှစ်ခု၊ စစ်ဆေးမှုနှစ်ခုလုပ်ဆောင်သည်။ ပထမ PR ကို ဖွံ့ဖြိုးတိုးတက်အောင် ပေါင်းစည်းပြီးနောက် ဒုတိယတစ်ခုကို ပြန်လည်တည်ဆောက်ရန် လိုအပ်သည်။ စုစုပေါင်း၊ PR နှစ်ခုသည် စစ်ဆေးမှုသုံးကြိမ် လိုအပ်သည်- 2 + 1 = 3။

မူအရတော့ ကောင်းပါတယ်။ ဒါပေမယ့် ကျွန်တော်တို့ စာရင်းဇယားတွေကို ကြည့်လိုက်တော့ ကျွန်တော်တို့အဖွဲ့ရဲ့ ပုံမှန်အခြေအနေက 10 ပွင့် PR တွေဖြစ်ပြီး စစ်ဆေးမှုအရေအတွက်က တိုးတက်မှုရဲ့ ပေါင်းလဒ်ဖြစ်ပါတယ်- 10 + 9 + ... + 1 = 55 ။ ဆိုလိုသည်မှာ 10 ကို လက်ခံရန်၊ PRs များကို 55 ကြိမ် ပြန်လည်တည်ဆောက်ရန် လိုအပ်ပါသည်။ ဤဒါဇင်များကို လုပ်ဆောင်နေစဉ်တွင် စစ်ဆေးမှုအားလုံးသည် ပထမအကြိမ် အောင်မြင်သွားသောအခါ၊ ဤဒါဇင်များကို လုပ်ဆောင်နေချိန်တွင် နောက်ထပ်ဆွဲတင်တောင်းဆိုမှုကို မည်သူမျှ မဖွင့်သည့်အခါ ၎င်းသည် စံပြအခြေအနေတစ်ခုဖြစ်သည်။

“ပေါင်းစပ်ခြင်း” ခလုတ်ကို ပထမဆုံးနှိပ်ရန် သင့်ကိုယ်သင် ဆော့ဖ်ဝဲရေးသားသူအဖြစ် မြင်ယောင်ကြည့်ပါ၊ အကြောင်းမှာ အိမ်နီးနားချင်းက ထိုသို့လုပ်ဆောင်ပါက၊ တည်ဆောက်မှုအားလုံး နောက်တစ်ကြိမ် ထပ်မပြီးမချင်း စောင့်ရလိမ့်မည်... မဟုတ်ပါ၊ အလုပ်မဖြစ်ပါ။ ဖွံ့ဖြိုးတိုးတက်မှုကို ဆိုးရွားစွာ နှေးကွေးစေမည်ဖြစ်သည်။

ဒုတိယဖြစ်နိုင်သောနည်းလမ်း ကုဒ်ပြန်လည်သုံးသပ်ပြီးနောက် ဆွဲယူတောင်းဆိုမှုများကို စုဆောင်းပါ။ ဆိုလိုသည်မှာ သင်သည် ဆွဲယူတောင်းဆိုမှုကို ဖွင့်ပါ၊ လုပ်ဖော်ကိုင်ဖက်များထံမှ လိုအပ်သော အတည်ပြုချက်အရေအတွက်ကို စုဆောင်းပါ၊ လိုအပ်သည်များကို ပြုပြင်ပါ၊ ထို့နောက် တည်ဆောက်မှုများကို စတင်ပါ။ ၎င်းတို့အောင်မြင်ပါက၊ ဆွဲတင်တောင်းဆိုမှုကို ဖွံ့ဖြိုးတိုးတက်စေရန် ပေါင်းစပ်ထားသည်။ ဤကိစ္စတွင်၊ နောက်ထပ်ပြန်လည်စတင်ခြင်းမျိုးမရှိသော်လည်း တုံ့ပြန်ချက်သည် အလွန်နှေးကွေးသွားပါသည်။ ဆော့ဖ်ဝဲရေးသားသူအနေဖြင့်၊ ဆွဲတင်တောင်းဆိုမှုတစ်ခုကို ကျွန်ုပ်ဖွင့်သည့်အခါ ၎င်းသည် အလုပ်ဖြစ်မဖြစ်ကို ချက်ချင်းကြည့်ချင်ပါသည်။ ဥပမာအားဖြင့်၊ စမ်းသပ်မှုတစ်ခုပျက်ကွက်ပါက၊ ၎င်းကိုအမြန်ပြင်ရန်လိုအပ်သည်။ တည်ဆောက်မှုနှောင့်နှေးသောအခါတွင်၊ တုံ့ပြန်ချက် နှေးကွေးပြီး ဖွံ့ဖြိုးတိုးတက်မှုတစ်ခုလုံးကို လုပ်ဆောင်သည်။ ဒါက ငါတို့နဲ့လည်း မကိုက်ညီဘူး။

ရလဒ်အနေနဲ့ တတိယရွေးချယ်မှုသာ ကျန်ရှိတော့သည်- စက်ဘီး. ကျွန်ုပ်တို့၏ကုဒ်အားလုံး၊ ကျွန်ုပ်တို့၏ရင်းမြစ်အားလုံးကို Bitbucket ဆာဗာရှိ သိုလှောင်ရုံတစ်ခုတွင် သိမ်းဆည်းထားသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Bitbucket အတွက် ပလပ်အင်တစ်ခုကို တီထွင်ရန် လိုအပ်ပါသည်။

ဤပလပ်အင်သည် ဆွဲယူတောင်းဆိုမှု ပေါင်းစည်းခြင်း ယန္တရားကို အစားထိုးသည်။ အစမှာ စံဖြစ်သည်- PR ကိုဖွင့်သည်၊ စည်းဝေးပွဲအားလုံးကို စတင်သည်၊ ကုဒ်ပြန်လည်သုံးသပ်ခြင်း ပြီးမြောက်သည်။ သို့သော် ကုဒ်ပြန်လည်သုံးသပ်ခြင်းကို ပြီးမြောက်ပြီး developer မှ "merge" ကိုနှိပ်ရန် ဆုံးဖြတ်ပြီးနောက်၊ plugin သည် checks များကို run သည့် develop state ကိုစစ်ဆေးသည်။ တည်ဆောက်မှုများပြီးနောက် develop ကို အပ်ဒိတ်လုပ်ပြီးပါက၊ plugin သည် ထိုကဲ့သို့သော ဆွဲငင်တောင်းဆိုမှုကို ပင်မဌာနခွဲသို့ ပေါင်းစည်းရန် ခွင့်ပြုမည်မဟုတ်ပါ။ ၎င်းသည် မကြာသေးမီက တည်ဆောက်မှုများ၏ တည်ဆောက်မှုများကို ရိုးရှင်းစွာ ပြန်လည်စတင်မည်ဖြစ်သည်။

ကွဲလွဲနေသောပြောင်းလဲမှုများနှင့် ကျွန်ုပ်တို့၏နမူနာတွင်၊ စုစည်းမှုအမှားတစ်ခုကြောင့်၊ ထိုသို့သောတည်ဆောက်မှုများသည် ကျရှုံးလိမ့်မည်။ ထို့ကြောင့်၊ အင်္ဂါရပ် B ၏ developer သည် ကုဒ်ကို ပြုပြင်ရန်၊ စစ်ဆေးမှုများကို ပြန်လည်စတင်ရမည်ဖြစ်ပြီး၊ ထို့နောက် ပလပ်အင်သည် ဆွဲယူတောင်းဆိုမှုကို အလိုအလျောက် အသုံးပြုမည်ဖြစ်သည်။

ဤပလပ်အင်ကို အကောင်အထည်မဖော်မီ၊ ဆွဲယူတောင်းဆိုမှုတစ်ခုလျှင် ပြန်လည်သုံးသပ်မှု 2,7 ကို ပျမ်းမျှလုပ်ဆောင်ခဲ့သည်။ ပလပ်အင်နှင့်အတူ 3,6 လွှင့်တင်မှုများရှိခဲ့သည်။ ဒါက ငါတို့နဲ့ သင့်တော်တယ်။

ဤပလပ်အင်တွင် အားနည်းချက်တစ်ခုရှိသည်ကို သတိပြုသင့်သည်- ၎င်းသည် တည်ဆောက်မှုကို တစ်ကြိမ်သာ ပြန်လည်စတင်သည်။ ဆိုလိုသည်မှာ၊ ကွဲလွဲနေသော အပြောင်းအလဲများ ဖြစ်ပေါ်လာနိုင်သည့် သေးငယ်သော ပြတင်းပေါက်တစ်ခု ရှိပါသေးသည်။ ဒါပေမယ့် ဒါက ဖြစ်နိုင်ခြေနည်းပါတယ်၊ စတင်တဲ့အရေအတွက်နဲ့ ကျရှုံးနိုင်ခြေကြား အပေးအယူလုပ်ထားပါတယ်။ နှစ်နှစ်အတွင်းမှာ တစ်ကြိမ်သာ ပစ်ခတ်တဲ့အတွက် အချည်းနှီးဖြစ်မှာ မဟုတ်ပါဘူး။

Bitbucket ပလပ်အင်၏ ပထမဆုံးဗားရှင်းကို ရေးသားရန် ကျွန်ုပ်တို့ နှစ်ပတ်ကြာခဲ့သည်။

အသစ်စစ်ဆေးမှုများ

ထိုအချိန်တွင် ကျွန်ုပ်တို့အဖွဲ့သည် ဆက်လက်တိုးတက်နေပါသည်။ စစ်ဆေးမှုအသစ်များ ထည့်သွင်းထားသည်။

တားဆီးနိုင်လျှင် အဘယ်ကြောင့် အမှားလုပ်မိကြသနည်း။ အဲဒါကြောင့် သူတို့က အကောင်အထည်ဖော်တယ်။ static code ခွဲခြမ်းစိတ်ဖြာခြင်း။. ကျွန်ုပ်တို့သည် Android SDK တွင်ပါဝင်သည့် lint ဖြင့်စတင်ခဲ့သည်။ သို့သော် ထိုအချိန်တွင် သူသည် Kotlin ကုဒ်ဖြင့် မည်သို့လုပ်ဆောင်ရမည်ကို လုံးဝမသိခဲ့ဘဲ၊ ကျွန်ုပ်တို့တွင် Kotlin ဖြင့် ရေးသားထားသော လျှောက်လွှာ၏ 75% ရှိနေပြီဖြစ်သည်။ ထို့ကြောင့် ပိုးမွှားများကို ပိုးမွှားများတွင် ထည့်သွင်းထားသည်။ Android Studio စစ်ဆေးမှုများ။

ဒါကိုလုပ်ဖို့၊ ကျွန်ုပ်တို့သည် လှည့်စားခြင်းများစွာကို ပြုလုပ်ရပါသည်- Android Studio ကိုယူ၍ ၎င်းကို Docker တွင် ထုပ်ပိုးပြီး CI ပေါ်တွင် virtual မော်နီတာတစ်ခုဖြင့် ဖွင့်ထားသောကြောင့် ၎င်းသည် တကယ့်လက်ပ်တော့တစ်လုံးပေါ်တွင် လည်ပတ်နေသည်ဟု ထင်စေသည်။ ဒါပေမယ့် အလုပ်လုပ်တယ်။

ဒီအချိန်မှာလည်း စာတွေ အများကြီး စရေးဖြစ်ခဲ့ပါတယ်။ ကိရိယာစမ်းသပ်မှုများ နှင့်အကောင်အထည်ဖော်ခဲ့သည်။ screenshot စမ်းသပ်ခြင်း။. ဤသည်မှာ သီးခြားအသေးစားမြင်ကွင်းတစ်ခုအတွက် ရည်ညွှန်းဖန်သားပြင်ဓာတ်ပုံကို ဖန်တီးသည့်အခါဖြစ်ပြီး၊ စမ်းသပ်မှုတွင် မြင်ကွင်းမှ ဖန်သားပြင်ဓာတ်ပုံကိုယူပြီး ၎င်းကို စံ pixel ဖြင့် တိုက်ရိုက် pixel နှင့် နှိုင်းယှဉ်ခြင်း ပါဝင်ပါသည်။ ကွဲလွဲမှုရှိပါက၊ အပြင်အဆင်သည် တစ်နေရာရာတွင် မှားယွင်းသွားခြင်း သို့မဟုတ် ပုံစံများတွင် တစ်ခုခုမှားနေသည်ဟု ဆိုလိုသည်။

သို့သော် ကိရိယာစမ်းသပ်မှုများနှင့် ဖန်သားပြင်ဓာတ်ပုံစမ်းသပ်မှုများကို စက်ပစ္စည်းများတွင် လုပ်ဆောင်ရန် လိုအပ်သည်- emulators များပေါ်တွင် သို့မဟုတ် တကယ့်ကိရိယာများတွင် ဖြစ်သည်။ စစ်ဆေးမှုများစွာရှိပြီး ၎င်းတို့ကို မကြာခဏလုပ်ဆောင်သည်ဟု ယူဆပါက လယ်ယာတစ်ခုလုံး လိုအပ်ပါသည်။ သင့်ကိုယ်ပိုင်ခြံကို စတင်ခြင်းသည် လုပ်သားအင်အား အလွန်အကျွံဖြစ်သောကြောင့် အဆင်သင့်လုပ်ထားသော ရွေးချယ်မှုတစ်ခု - Firebase Test Lab ကို တွေ့ရှိခဲ့သည်။

Firebase စမ်းသပ်ခန်း

Firebase သည် Google ထုတ်ကုန်တစ်ခုဖြစ်သောကြောင့် ၎င်းကိုရွေးချယ်ခဲ့ခြင်းမှာ ယုံကြည်စိတ်ချရပြီး သေဆုံးရန်မဖြစ်နိုင်ဟု ဆိုလိုခြင်းဖြစ်သည်။ ဈေးနှုန်းများသည် ကျိုးကြောင်းဆီလျော်သည်- စစ်မှန်သောကိရိယာ၏လည်ပတ်မှုတစ်နာရီလျှင် $5၊ emulator တစ်ခု၏လည်ပတ်မှုတစ်နာရီလျှင် $1။

Firebase Test Lab ကို ကျွန်ုပ်တို့၏ CI တွင် အကောင်အထည်ဖော်ရန် ခန့်မှန်းခြေအားဖြင့် သုံးပတ်ခန့် အချိန်ယူရပါသည်။

သို့သော် အဖွဲ့သည် ဆက်လက်ကြီးထွားလာပြီး Firebase သည် ကံမကောင်းစွာဖြင့် ကျွန်တော်တို့ကို နှိမ့်ချစပြုလာသည်။ အဲဒီတုန်းက သူ့မှာ SLA မရှိဘူး။ တစ်ခါတစ်ရံတွင် Firebase သည် လိုအပ်သော စက်ပစ္စည်းအရေအတွက်ကို စမ်းသပ်ရန် အခမဲ့ဖြစ်သည်အထိ ကျွန်ုပ်တို့အား စောင့်ခိုင်းပြီး ကျွန်ုပ်တို့အလိုရှိသကဲ့သို့ ၎င်းတို့ကို ချက်ချင်းမလုပ်ဆောင်နိုင်ပါ။ တန်းစီစောင့်ဆိုင်းရသည်မှာ နာရီဝက်ခန့်ကြာမြင့်ပြီး အလွန်ကြာမြင့်ပါသည်။ PR တစ်ခုစီတိုင်းတွင် ကိရိယာတန်ဆာပလာစစ်ဆေးမှုများကို လုပ်ဆောင်ခဲ့ပြီး၊ နှောင့်နှေးမှုများသည် ဖွံ့ဖြိုးတိုးတက်မှုကို အမှန်တကယ် နှေးကွေးစေသည်၊ ထို့နောက် လစဉ်ငွေတောင်းခံလွှာသည် အလုံးအရင်းဖြင့် ရောက်ရှိလာပါသည်။ ယေဘုယျအားဖြင့်၊ အဖွဲ့သည် အလုံအလောက်ကြီးထွားလာသောကြောင့် Firebase ကို စွန့်လွှတ်ပြီး အိမ်တွင်းအလုပ်လုပ်ရန် ဆုံးဖြတ်ခဲ့သည်။

Docker + Python + bash

ကျွန်ုပ်တို့သည် Docker ကိုယူ၍ ၎င်းတွင်ထည့်သွင်းထားသော emulators များကို Python တွင် ရိုးရှင်းသောပရိုဂရမ်တစ်ခုရေးခဲ့သည်၊ မှန်ကန်သည့်အချိန်တွင် လိုအပ်သော emulator အရေအတွက်ကို မှန်ကန်သောဗားရှင်းတွင်စတင်ပြီး လိုအပ်သည့်အခါတွင် ၎င်းတို့ကိုရပ်တန့်စေသည်။ ပြီးတော့ bash scripts နှစ်ခု - အဲဒါတွေမပါဘဲ ငါတို့ဘယ်မှာရှိမလဲ။

ကျွန်ုပ်တို့၏ကိုယ်ပိုင်စမ်းသပ်မှုပတ်ဝန်းကျင်ကိုဖန်တီးရန် ငါးပတ်ကြာသည်။

ရလဒ်အနေဖြင့်၊ ဆွဲယူတောင်းဆိုမှုတိုင်းအတွက် ကျယ်ပြန့်သော ပေါင်းစည်းမှု-ပိတ်ဆို့ခြင်းဆိုင်ရာ စစ်ဆေးချက်စာရင်းတစ်ခု ရှိပါသည်-

• ARK စည်းဝေးပွဲ;
• Junit စမ်းသပ်မှုများ;
• ပျား၊
• Android Studio စစ်ဆေးမှုများ၊
• တူရိယာစမ်းသပ်မှုများ;
• Screenshot စမ်းသပ်မှုများ။

ယင်းက ဖြစ်နိုင်ချေရှိသော ပြိုကွဲမှုများစွာကို တားဆီးခဲ့သည်။ နည်းပညာအရ အရာရာတိုင်းသည် အလုပ်ဖြစ်ခဲ့သော်လည်း ရလဒ်များကို စောင့်ရသည်မှာ ကြာလွန်းသည်ဟု developer များက စောဒကတက်ကြသည်။

ဘယ်လောက်ကြာလဲ? ကျွန်ုပ်တို့သည် Bitbucket နှင့် TeamCity မှ ဒေတာများကို ခွဲခြမ်းစိတ်ဖြာမှုစနစ်သို့ အပ်လုဒ်လုပ်ကာ ၎င်းကို သဘောပေါက်ပါသည်။ ပျမ်းမျှစောင့်ဆိုင်းချိန် 45 မိနစ်. ဆိုလိုသည်မှာ developer သည် ဆွဲယူတောင်းဆိုမှုကိုဖွင့်သောအခါ တည်ဆောက်မှုရလဒ်များအတွက် ပျမ်းမျှ 45 မိနစ်စောင့်သည်။ ကျွန်တော့်အမြင်အရတော့ ဒါက အများကြီးပဲ၊ မင်းအဲဒီလိုလုပ်လို့မရဘူး။

ဟုတ်ပါတယ်၊ ကျွန်ုပ်တို့ရဲ့ တည်ဆောက်မှုအားလုံးကို အရှိန်မြှင့်ဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။

အရှိန်မြှင့်လိုက်ရအောင်

အဆောက်အအုံတွေ တန်းစီနေလေ့ရှိတာကို တွေ့ရတော့ ကျွန်တော်တို့ ပထမဆုံးလုပ်တာက Hardware တွေ ပိုဝယ်လာတယ်။ - ကျယ်ပြန့်သောဖွံ့ဖြိုးတိုးတက်မှုသည် အရိုးရှင်းဆုံးဖြစ်သည်။ အဆောက်အအုံများသည် တန်းစီစောင့်ဆိုင်းခြင်းကို ရပ်သွားသော်လည်း အချို့သောစစ်ဆေးမှုများသည် အချိန်အလွန်ကြာမြင့်သောကြောင့် စောင့်ဆိုင်းချိန်အနည်းငယ်သာ လျော့နည်းသွားသည်။

ကြာမြင့်လွန်းသော စစ်ဆေးမှုများကို ဖယ်ရှားခြင်း။

ကျွန်ုပ်တို့၏ စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုသည် ဤအမှားများနှင့် ပြဿနာအမျိုးအစားများကို ဖမ်းစားနိုင်မည်ဖြစ်သည်။

• မသွားဘူး။. ကွဲလွဲနေသောပြောင်းလဲမှုများကြောင့် တစ်ခုခုမတည်ဆောက်သည့်အခါ CI သည် စုစည်းမှုအမှားကို ဖမ်းမိနိုင်သည်။ ငါပြောခဲ့သလိုပဲ၊ ဘယ်အရာမှ စုစည်းလို့ မရတော့ဘူး၊ ဖွံ့ဖြိုးတိုးတက်မှု ရပ်တန့်သွားပြီး လူတိုင်းက တုန်လှုပ်ချောက်ချားသွားကြပါတယ်။
• အကျင့်စာရိတ္တချို့ယွင်းခြင်း။. ဥပမာအားဖြင့်၊ အပလီကေးရှင်းကိုတည်ဆောက်သောအခါတွင်၊ သင်ခလုတ်တစ်ခုကိုနှိပ်သောအခါပျက်သွားသည်၊ သို့မဟုတ်ခလုတ်ကိုလုံးဝမနှိပ်ပါ။ ထိုသို့သော ချွတ်ယွင်းချက်သည် အသုံးပြုသူထံ ရောက်ရှိနိုင်သောကြောင့် ၎င်းသည် မကောင်းပါ။
• အပြင်အဆင်တွင် ချွတ်ယွင်းချက်. ဥပမာအားဖြင့်၊ ခလုတ်တစ်ခုကို နှိပ်လိုက်သော်လည်း 10 pixels ကို ဘယ်ဘက်သို့ ရွှေ့ထားသည်။
• နည်းပညာဆိုင်ရာ အကြွေးများ တိုးလာသည်။.

ဤစာရင်းကိုကြည့်ပြီးနောက် ပထမအချက်နှစ်ချက်သာ အရေးကြီးကြောင်း ကျွန်ုပ်တို့သဘောပေါက်ပါသည်။ ဒီလိုပြဿနာတွေကို အရင်ဖမ်းချင်တယ်။ အပြင်အဆင်ရှိ ချို့ယွင်းချက်များကို ဒီဇိုင်းပြန်လည်သုံးသပ်သည့်အဆင့်တွင် တွေ့ရှိပြီး အလွယ်တကူ ပြင်ဆင်နိုင်သည်။ နည်းပညာဆိုင်ရာကြွေးမြီများကို ကိုင်တွယ်ဖြေရှင်းရာတွင် သီးခြားလုပ်ငန်းစဉ်နှင့် အစီအစဉ်ဆွဲရန် လိုအပ်သောကြောင့် ၎င်းကို ဆွဲထုတ်ရန် တောင်းဆိုမှုဖြင့် ၎င်းကို စမ်းသပ်ရန် ဆုံးဖြတ်ခဲ့သည်။

ဤအမျိုးအစားခွဲခြားမှုအပေါ်အခြေခံ၍ ကျွန်ုပ်တို့သည် စစ်ဆေးမှုစာရင်းတစ်ခုလုံးကို တုန်လှုပ်စေပါသည်။ လင်းကိုဖြတ်လိုက်သည်။ ပရောဂျက်တွင် ပြဿနာမည်မျှရှိသည်ကို အစီရင်ခံစာထုတ်နိုင်ရန် တစ်ညလုံး ရွှေ့ဆိုင်းခဲ့သည်။ နည်းပညာဆိုင်ရာကြွေးမြီများနှင့် သီးခြားစီလုပ်ဆောင်ရန် သဘောတူညီခဲ့ကြသည်။ Android Studio စစ်ဆေးမှုများကို လုံးဝ စွန့်လွှတ်လိုက်ပါပြီ။. စစ်ဆေးမှုများ လုပ်ဆောင်ရန်အတွက် Docker ရှိ Android Studio သည် စိတ်ဝင်စားဖွယ်ကောင်းသော်လည်း ပံ့ပိုးမှုတွင် အခက်အခဲများစွာ ဖြစ်စေသည်။ Android Studio ဗားရှင်းများအတွက် အပ်ဒိတ်မှန်သမျှသည် နားမလည်နိုင်သော ချို့ယွင်းချက်များနှင့် ရုန်းကန်နေရခြင်းကို ဆိုလိုသည်။ ဒစ်ဂျစ်တိုက်သည် အလွန်တည်ငြိမ်မှုမရှိ၍ မှားယွင်းသောအပြုသဘောများရှိနေသောကြောင့် ဖန်သားပြင်ဓာတ်ပုံစစ်ဆေးမှုများကို ပံ့ပိုးရန်လည်း ခက်ခဲပါသည်။ ဖန်သားပြင်ဓာတ်ပုံစစ်ဆေးမှုများကို စစ်ဆေးစာရင်းမှ ဖယ်ရှားလိုက်ပါပြီ။.

ရလဒ်အနေဖြင့်၊

• ARK စည်းဝေးပွဲ;
• Junit စမ်းသပ်မှုများ;
• တူရိယာစမ်းသပ်မှုများ။

Gradle အဝေးကက်ရှ်

အပြင်းအထန်စစ်ဆေးမှုတွေမလုပ်ဘဲ အရာအားလုံးက ပိုကောင်းလာတယ်။ ဒါပေမယ့် ပြီးပြည့်စုံဖို့ ကန့်သတ်ချက်မရှိပါဘူး။

ကျွန်ုပ်တို့၏လျှောက်လွှာကို gradle modules 150 ခန့်ခွဲပြီးဖြစ်သည်။ Gradle အဝေးထိန်း ကက်ရှ်သည် များသောအားဖြင့် ဤကိစ္စတွင် ကောင်းမွန်စွာ အလုပ်လုပ်သောကြောင့် ၎င်းကို စမ်းကြည့်ရန် ဆုံးဖြတ်ခဲ့သည်။

Gradle remote cache သည် တစ်ခုချင်းစီ modules တစ်ခုစီတွင် အလုပ်တစ်ခုစီအတွက် artifact များကို တည်ဆောက်နိုင်သော ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ Gradle သည် ကုဒ်ကို အမှန်တကယ် စုစည်းမည့်အစား အဝေးထိန်း ကက်ရှ်ကို ခေါက်ရန်နှင့် တစ်စုံတစ်ယောက်သည် ဤလုပ်ငန်းကို လုပ်ဆောင်ပြီးပြီလားဟု မေးရန် HTTP ကို ​​အသုံးပြုသည်။ ဟုတ်ရင် ရလဒ်ကို ဒေါင်းလုဒ်လုပ်ရုံပါပဲ။

Gradle သည် Docker ပုံကို ပံ့ပိုးပေးသောကြောင့် Gradle အဝေးထိန်းကက်ရှ်ကို လုပ်ဆောင်ခြင်းသည် လွယ်ကူသည်။ ဒါကို သုံးနာရီအတွင်း ကျွန်တော်တို့ လုပ်နိုင်ခဲ့တယ်။

သင်လုပ်ရမှာက Docker ကိုဖွင့်ပြီး ပရောဂျက်မှာ စာကြောင်းတစ်ကြောင်းရေးပါ။ ဒါပေမယ့် မြန်မြန်ဆန်ဆန် စတင်နိုင်ပေမယ့် အရာအားလုံး အဆင်ပြေဖို့ အချိန်တော်တော်ယူရပါလိမ့်မယ်။

အောက်တွင် cache misses ဂရပ်ဖစ်သည်။

အစပိုင်းတွင်၊ ကက်ရှ်လွဲချော်မှုရာခိုင်နှုန်းသည် ၆၅ ခန့်ရှိသည်။ သုံးပတ်ကြာပြီးနောက်၊ ကျွန်ုပ်တို့သည် ဤတန်ဖိုးကို 65% အထိ တိုးမြှင့်နိုင်ခဲ့သည်။ Gradle သည် ကက်ရှ်ကိုလွတ်သွားသောကြောင့် Android အပလီကေးရှင်းမှစုဆောင်းသည့်အလုပ်များသည် ထူးဆန်းသောအကူးအပြောင်းမှီခိုမှုများရှိသည်ကိုတွေ့ရှိခဲ့ရသည်။

ကက်ရှ်ကို ချိတ်ဆက်ခြင်းဖြင့် တည်ဆောက်မှုကို ကျွန်ုပ်တို့ အလွန်အရှိန်မြှင့်ခဲ့သည်။ ဒါပေမယ့် တပ်ဆင်မှုအပြင်၊ ကိရိယာတန်ဆာပလာ စမ်းသပ်မှုတွေလည်း ရှိပြီး အချိန်ကြာပါတယ်။ ဆွဲငင်တောင်းဆိုမှုတိုင်းအတွက် စမ်းသပ်မှုအားလုံးကို လုပ်ဆောင်ရန်မလိုအပ်ပါ။ သိရှိရန် ကျွန်ုပ်တို့သည် သက်ရောက်မှုခွဲခြမ်းစိတ်ဖြာမှုကို အသုံးပြုပါသည်။

သက်ရောက်မှုခွဲခြမ်းစိတ်ဖြာ

တောင်းဆိုချက်တစ်ခုတွင်၊ ကျွန်ုပ်တို့သည် git diff ကိုစုဆောင်းပြီး ပြုပြင်ထားသော Gradle modules ကိုရှာပါ။

ပြောင်းလဲထားသော module များနှင့် ၎င်းတို့အပေါ် မူတည်သော module အားလုံးကို စစ်ဆေးသော instrumentation tests များကိုသာ run ခြင်းသည် အဓိပ္ပါယ်ရှိပေသည်။ အိမ်နီးနားချင်း module များအတွက် စမ်းသပ်မှုများ လုပ်ဆောင်ရာတွင် အမှတ်မရှိပါ- ထိုနေရာတွင် ကုဒ်သည် ပြောင်းလဲ၍ ဘာမှမကွဲနိုင်ပါ။

ကိရိယာတန်ဆာပလာစစ်ဆေးမှုများသည် ရိုးရှင်းခြင်းမရှိပါ၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် ထိပ်တန်းအဆင့် အပလီကေးရှင်း module တွင် တည်ရှိနေရပါမည်။ စမ်းသပ်မှုတစ်ခုစီတွင် မည်သည့် module တစ်ခုစီပါရှိသည်ကို နားလည်ရန် bytecode ခွဲခြမ်းစိတ်ဖြာမှုဖြင့် heuristics ကို အသုံးပြုခဲ့သည်။

ပါဝင်သည့် modules များကိုသာ စမ်းသပ်ရန်အတွက် ကိရိယာတန်ဆာပလာစစ်ဆေးမှုများ၏ လုပ်ဆောင်ချက်ကို အဆင့်မြှင့်တင်ခြင်းမှာ ရှစ်ပတ်ခန့်ကြာပါသည်။

စစ်ဆေးမှု အရှိန်မြှင့် ဆောင်ရွက်ချက်များ အောင်မြင်စွာ ဆောင်ရွက်ခဲ့ပါသည်။ ၄၅ မိနစ်မှ ၁၅ နာရီခန့်အထိ တက်သွားသည်။ တည်ဆောက်မှုတစ်ခုအတွက် တစ်နာရီ၏လေးပုံတစ်ပုံကို စောင့်ရသည်မှာ ပုံမှန်ဖြစ်နေပါပြီ။

ယခုမူ developer များသည် မည်သည့် build များကို စတင်လုပ်ဆောင်နေသည်၊ မှတ်တမ်းကို မည်သည့်နေရာတွင် မြင်ရမည်၊ အဘယ်ကြောင့် အနီရောင်ဖြစ်သည်၊ စမ်းသပ်မှု မအောင်မြင်သည့် စသည်ဖြင့် နားမလည်ကြောင်း developer များက စတင်တိုင်ကြားလာကြသည်။

တုံ့ပြန်ချက်နှင့်အတူ ပြဿနာများသည် ဖွံ့ဖြိုးတိုးတက်မှုကို နှေးကွေးစေသောကြောင့် PR တစ်ခုစီ၏ အသေးစိတ်အချက်အလက်များကို ရှင်းလင်းပြီး တတ်နိုင်သမျှ တည်ဆောက်ရန် ကျွန်ုပ်တို့ ကြိုးစားခဲ့သည်။ ကျွန်ုပ်တို့သည် မည်သည့်တည်ဆောက်မှုမှ မအောင်မြင်ခဲ့ကြောင်း၊ အဘယ်ကြောင့်ဆိုသော် PR သို့ Bitbucket တွင် မှတ်ချက်များဖြင့် စတင်ခဲ့ပြီး Slack တွင် ပစ်မှတ်ထားသော စာတိုများကို ရေးသားခဲ့သည်။ အဆုံးတွင်၊ ကျွန်ုပ်တို့သည် လက်ရှိလုပ်ဆောင်နေသည့် တည်ဆောက်မှုများနှင့် ၎င်းတို့၏အခြေအနေ- တန်းစီနေခြင်း၊ လည်ပတ်နေခြင်း၊ ပျက်သွားခြင်း သို့မဟုတ် ပြီးစီးမှုစာရင်းနှင့်အတူ စာမျက်နှာအတွက် PR ဒက်ရှ်ဘုတ်တစ်ခု ဖန်တီးခဲ့သည်။ တည်ဆောက်မှုကို နှိပ်ပြီး ၎င်း၏မှတ်တမ်းသို့ သင်ရောက်ရှိနိုင်သည်။

အသေးစိတ်တုံ့ပြန်ချက်အတွက် ခြောက်ပတ်ကြာ အသုံးပြုခဲ့သည်။

အစီအစဉ်များ

မကြာသေးမီက သမိုင်းကို ဆက်သွားကြပါစို့။ တုံ့ပြန်ချက်ပြဿနာကို ဖြေရှင်းပြီးနောက် အဆင့်အသစ်တစ်ခုသို့ ရောက်ရှိခဲ့သည် - ကျွန်ုပ်တို့၏ကိုယ်ပိုင် emulator ခြံကို တည်ဆောက်ရန် ဆုံးဖြတ်ခဲ့သည်။ စမ်းသပ်မှုများနှင့် emulator များစွာရှိသောအခါ၊ ၎င်းတို့သည် စီမံခန့်ခွဲရန် ခက်ခဲသည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့၏ emulator များအားလုံးသည် ပြောင်းလွယ်ပြင်လွယ်ရှိသော အရင်းအမြစ်စီမံခန့်ခွဲမှုဖြင့် k8s အစုအဝေးသို့ ပြောင်းရွှေ့ခဲ့သည်။

ထို့အပြင် အခြားသော အစီအစဉ်များလည်း ရှိသေးသည်။

• Lint ပြန်သွားပါ။ (အခြား static analysis)။ ကျွန်တော်တို့က ဒီဦးတည်ချက်ကို လုပ်ဆောင်နေပြီ။
• PR blocker တွင် အရာအားလုံးကို လုပ်ဆောင်ပါ။ အဆုံးမှ အဆုံး စမ်းသပ်မှုများ SDK ဗားရှင်းအားလုံးတွင်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Avito တွင် စဉ်ဆက်မပြတ် ပေါင်းစည်းမှု ဖွံ့ဖြိုးတိုးတက်မှု၏ သမိုင်းကြောင်းကို ခြေရာခံလိုက်ပါပြီ။ အခုကျွန်တော်က အတွေ့အကြုံရှိတဲ့ အမြင်ကနေ အကြံဥာဏ်လေး ပေးချင်ပါတယ်။

သိကောင်းစရာများ

အကြံဉာဏ်တစ်ခုလောက်သာ ပေးနိုင်ရင် ဒါက ဒီလိုဖြစ်လိမ့်မယ်။

ကျေးဇူးပြု၍ shell scripts များကို သတိထားပါ။

Bash သည် အလွန်ပြောင်းလွယ်ပြင်လွယ်နှင့် အစွမ်းထက်သည့်ကိရိယာတစ်ခုဖြစ်ပြီး scripts များရေးသားရာတွင် အလွန်အဆင်ပြေပြီး မြန်ဆန်သည်။ ဒါပေမယ့် မင်း အဲဒါနဲ့ ထောင်ချောက်ထဲ ကျသွားနိုင်တယ်၊ ကံမကောင်းစွာပဲ၊ ငါတို့ အဲဒီထဲကို ကျသွားနိုင်တယ်။

၎င်းသည် ကျွန်ုပ်တို့၏တည်ဆောက်စက်များတွင် ရိုးရှင်းသော ဇာတ်ညွှန်းများဖြင့် စတင်ခဲ့သည်-

#!/usr/bin/env bash
./gradlew assembleDebug

ဒါပေမယ့် မင်းသိတဲ့အတိုင်းပဲ၊ အရာအားလုံးဟာ အချိန်ကြာလာတာနဲ့အမျှ ပိုရှုပ်ထွေးလာပြီး - ဇာတ်ညွှန်းတစ်ခုကနေ နောက်တစ်ခုဆီပြေးလိုက်ရအောင်၊ အဲဒီမှာ ကန့်သတ်ချက်တချို့ကို ကျော်သွားရအောင် - အဆုံးမှာ ငါတို့အခု bash nesting အဆင့်မှာ ဘယ်အဆင့်ရောက်နေပြီလဲဆိုတာကို ဆုံးဖြတ်တဲ့ function တစ်ခုကို ရေးရမှာပေါ့။ လိုအပ်သောကိုးကားချက်များထည့်သွင်းရန်၊ အားလုံးစတင်ရန်။

ထိုသို့သော ဇာတ်ညွှန်းများ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် လုပ်အားကုန်ကျစရိတ်ကို သင်စိတ်ကူးကြည့်နိုင်ပါသည်။ ဒီထောင်ချောက်ထဲကို မကျရောက်ဖို့ အကြံပေးပါရစေ။

အဘယ်အရာကို အစားထိုးနိုင်သနည်း။

• မည်သည့် scripting language ကိုမဆို။ သို့ စာရေးပါ။ Python သို့မဟုတ် Kotlin Script scripts မဟုတ်ဘဲ programming ကြောင့် ပိုအဆင်ပြေပါတယ်။
• သို့မဟုတ် ပုံစံတွင် တည်ဆောက်ထားသော လော့ဂျစ်အားလုံးကို ဖော်ပြပါ။ စိတ်ကြိုက် အဆင့်လုပ်စရာများ သင့်ပရောဂျက်အတွက်။

ကျွန်ုပ်တို့သည် ဒုတိယရွေးချယ်မှုကို ရွေးချယ်ရန် ဆုံးဖြတ်ခဲ့ပြီး ယခုအခါတွင် ကျွန်ုပ်တို့သည် bash script များအားလုံးကို စနစ်တကျ ဖျက်ကာ စိတ်ကြိုက် gradle လုပ်ဆောင်စရာများစွာကို ရေးသားနေပါသည်။

အကြံပြုချက် # 2- အခြေခံအဆောက်အဦများကို ကုဒ်တွင် သိမ်းဆည်းပါ။

Jenkins သို့မဟုတ် TeamCity စသည်တို့၏ UI အင်တာဖေ့စ်တွင် ဆက်တိုက်ပေါင်းစည်းခြင်းဆက်တင်ကို မသိမ်းဆည်းထားသော်လည်း ပရောဂျက်သိုလှောင်မှုတွင် တိုက်ရိုက်စာသားဖိုင်များပုံစံဖြင့် သိမ်းဆည်းသည့်အခါ အဆင်ပြေသည်။ ၎င်းသည် versionability ကိုပေးသည်။ အခြားဌာနခွဲတွင် ကုဒ်ကို ပြန်သိမ်းရန် သို့မဟုတ် ကုဒ်ကို တည်ဆောက်ရန် ခက်ခဲမည်မဟုတ်ပါ။

Script များကို ပရောဂျက်တစ်ခုတွင် သိမ်းဆည်းနိုင်သည်။ ပတ်ဝန်းကျင်နဲ့ ဘာလုပ်ရမလဲ။

အကြံပြုချက် # 3- Docker သည် ပတ်ဝန်းကျင်ကို ကူညီနိုင်သည်။

၎င်းသည် Android developer များအား သေချာပေါက် ကူညီပေးလိမ့်မည်၊ iOS တွင် တစ်ခုမျှ မရှိသေးပါ၊ ကံမကောင်းပါ။

ဤသည်မှာ jdk နှင့် android-sdk ပါရှိသော ရိုးရှင်းသော docker ဖိုင်တစ်ခု၏ ဥပမာတစ်ခုဖြစ်သည်။

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ဒီ Docker ဖိုင်ကိုရေးပြီး (လျှို့ဝှက်ချက်တစ်ခုပြောပြမယ်၊ ရေးစရာမလိုပေမယ့် GitHub က အဆင်သင့်လုပ်ထားတဲ့ ဆွဲထုတ်လိုက်ရုံပါပဲ) နဲ့ ပုံကို စုစည်းလိုက်တာနဲ့ သင် application ကိုတည်ဆောက်နိုင်တဲ့ virtual machine တစ်ခုကို သင်ရရှိမှာဖြစ်ပါတယ်။ Junit စမ်းသပ်မှုများကို လုပ်ဆောင်ပါ။

ယင်းကို နားလည်သဘောပေါက်ရသည့် အဓိကအကြောင်းရင်းနှစ်ရပ်မှာ အတိုင်းအတာနှင့် ထပ်တလဲလဲနိုင်မှုဖြစ်သည်။ docker ကိုသုံးပြီး၊ သင်သည် ယခင်တစ်ခုနှင့် အတိအကျတူညီသောပတ်ဝန်းကျင်ရှိမည့် တည်ဆောက်အေးဂျင့်တစ်ဒါဇင်ကို လျင်မြန်စွာပြုစုပျိုးထောင်နိုင်ပါသည်။ ၎င်းသည် CI အင်ဂျင်နီယာများ၏ဘဝပိုမိုလွယ်ကူစေသည်။ android-sdk ကို docker သို့တွန်းရန်အတော်လေးလွယ်ကူသည်၊ သို့သော် emulator များဖြင့်၎င်းသည်အနည်းငယ်ပိုခက်ခဲသည်- သင်အနည်းငယ်ပိုကြိုးစားရပါမည် (သို့မဟုတ်ပြီးသွားသော GitHub မှနောက်တဖန်ဒေါင်းလုဒ်လုပ်ရန်) ။

အကြံပြုချက် နံပါတ် 4- စစ်ဆေးခြင်းများသည် စစ်ဆေးခြင်းအတွက်မဟုတ်ဘဲ လူများအတွက် လုပ်ဆောင်ခြင်းဖြစ်ကြောင်း မမေ့ပါနှင့်။

မြန်မြန်ဆန်ဆန်နဲ့ အရေးအကြီးဆုံးကတော့၊ ရှင်းလင်းပြတ်သားတဲ့ တုံ့ပြန်ချက်ဟာ developer တွေအတွက် အလွန်အရေးကြီးပါတယ်- ဘယ်အရာက ပျက်သွားသလဲ၊ ဘယ်စမ်းသပ်မှုမှ မအောင်မြင်ဘူး၊ buildlog ကို ဘယ်မှာကြည့်လို့ရမလဲ။

အကြံပြုချက် #5- စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုကို ဖော်ဆောင်သည့်အခါ လက်တွေ့ကျသော သဘောထားရှိပါ။

သင်ဟန့်တားလိုသော အမှားအမျိုးအစားများ၊ အရင်းအမြစ်များ၊ အချိန်များနှင့် သင်သုံးစွဲလိုသော ကွန်ပျူတာအချိန်များကို ရှင်းရှင်းလင်းလင်း နားလည်ပါ။ ဥပမာအားဖြင့် အချိန်အလွန်ကြာသော စစ်ဆေးမှုများကို ညတွင်းချင်း ရွှေ့ဆိုင်းနိုင်သည်။ အလွန်အရေးကြီးသောအမှားများကို မဖမ်းမိသော သူများကို လုံးဝစွန့်ပစ်သင့်သည်။

အကြံပြုချက် #6- အဆင်သင့်လုပ်ထားသော ကိရိယာများကို အသုံးပြုပါ။

ယခု Cloud CI ကို ပံ့ပိုးပေးသော ကုမ္ပဏီများစွာရှိသည်။

ဒါက အသင်းငယ်တွေအတွက် ကောင်းမွန်တဲ့ အဖြေတစ်ခုပါ။ သင်ဘာမျှပံ့ပိုးရန်မလိုအပ်ပါ၊ ငွေအနည်းငယ်ပေးရုံ၊ သင်၏လျှောက်လွှာကိုတည်ဆောက်ပြီးကိရိယာတန်ဆာပလာစစ်ဆေးမှုများကိုပင်လုပ်ဆောင်ပါ။

အကြံပြုချက် # 7- အဖွဲ့ကြီးတစ်ခုတွင်၊ အိမ်တွင်းဖြေရှင်းချက်များသည် ပိုမိုအကျိုးအမြတ်များသည်။

သို့သော် မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင်၊ အဖွဲ့ကြီးထွားလာသည်နှင့်အမျှ၊ အိမ်တွင်းဖြေရှင်းချက်များသည် ပိုမိုအကျိုးအမြတ်များလာသည်။ ဒီဆုံးဖြတ်ချက်တွေနဲ့ ပတ်သက်ပြီး ပြဿနာတစ်ခုရှိတယ်။ စီးပွားရေးတွင် အမြတ်အစွန်းကို လျှော့နည်းစေသည့် ဥပဒေတစ်ခု ရှိသည်- မည်သည့်ပရောဂျက်တွင်မဆို၊ နောက်ဆက်တွဲတိုးတက်မှုတစ်ခုစီသည် ပို၍ပို၍ခက်ခဲလာပြီး ရင်းနှီးမြှုပ်နှံမှု ပိုများလာရန် လိုအပ်ပါသည်။

Continuous Integration အပါအဝင် ကျွန်ုပ်တို့၏ ဘဝတစ်ခုလုံးကို Economics က ဖော်ပြသည်။ ကျွန်ုပ်တို့၏ စဉ်ဆက်မပြတ် ပေါင်းစည်းမှု ဖွံ့ဖြိုးတိုးတက်ရေး အဆင့်တစ်ခုစီအတွက် လုပ်သားစရိတ်များ အချိန်ဇယားကို ကျွန်ုပ်တည်ဆောက်ခဲ့ပါသည်။

တိုးတက်မှုတိုင်းသည် ပို၍ပို၍ခက်ခဲလာသည်မှာ ထင်ရှားပါသည်။ ဤဂရပ်ကိုကြည့်လျှင် အသင်းအရွယ်အစားကြီးထွားမှုနှင့်အညီ စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုကို ဖွံ့ဖြိုးတိုးတက်ရန် လိုအပ်ကြောင်း သင်နားလည်နိုင်ပါသည်။ လူနှစ်ဦးပါသော အဖွဲ့တစ်ဖွဲ့အတွက်၊ အတွင်းပိုင်း emulator ခြံကို ရက်ပေါင်း 50 သုံးစွဲခြင်းသည် တော်ရုံတန်ရုံ စိတ်ကူးတစ်ခုဖြစ်သည်။ သို့သော် တစ်ချိန်တည်းတွင် အသင်းကြီးတစ်ခုအတွက်၊ ဆက်တိုက်ပေါင်းစည်းခြင်းကို လုံးဝမလုပ်ခြင်းသည် ပေါင်းစည်းခြင်းပြဿနာများ၊ ဆက်သွယ်ရေးကို ပြုပြင်ခြင်းစသဖြင့် ဖြစ်သောကြောင့် အကြံဥာဏ်ကောင်းတစ်ခုလည်းဖြစ်သည်။ အချိန်ပိုကြာလိမ့်မယ်။

လူတွေက ဈေးကြီးတယ်၊ အမှားလုပ်တတ်တယ်၊ ပျင်းတဲ့အတွက်ကြောင့် အလိုအလျောက်စနစ်လိုတယ် ဆိုတဲ့ အယူအဆနဲ့ စတင်ခဲ့တယ်။ ဒါပေမယ့် လူတွေလည်း အလိုအလျောက် ထွက်လာတယ်။ ထို့ကြောင့်၊ တူညီသောပြဿနာများအားလုံးသည် automation နှင့်သက်ဆိုင်သည်။

• Automation က ဈေးကြီးတယ်။ အလုပ်ချိန်ဇယားကို မှတ်ထားပါ။
• automation နဲ့ပတ်သက်လာရင် လူတွေက အမှားတွေလုပ်ကြတယ်။
• တစ်ခါတရံတွင် အရာအားလုံးသည် ထိုနည်းအတိုင်း လုပ်ဆောင်သောကြောင့် အလိုအလျောက်ပြန်လုပ်ရန် အလွန်ပျင်းသည်။ အဘယ်ကြောင့် အခြားအရာများကို တိုးတက်စေသနည်း၊ အဘယ်ကြောင့် ဤအဆက်မပြတ် ပေါင်းစည်းခြင်း

ဒါပေမယ့် ကျွန်တော့်မှာ စာရင်းဇယားတွေရှိတယ်- စည်းဝေးပွဲတွေရဲ့ 20% မှာ အမှားအယွင်းတွေ တွေ့တယ်။ ကျွန်ုပ်တို့၏ developer များသည် ကုဒ်ကို ညံ့ဖျင်းစွာ ရေးသားခြင်းကြောင့် မဟုတ်ပါ။ အဘယ်ကြောင့်ဆိုသော် developer များသည် အမှားအယွင်းတစ်ခုခုလုပ်မိပါက၊ ၎င်းသည် ဖွံ့ဖြိုးတိုးတက်မှုတွင် ပြီးဆုံးမည်မဟုတ်ကြောင်း၊ ၎င်းကို အလိုအလျောက်စစ်ဆေးမှုများဖြင့် ဖမ်းမိလိမ့်မည်ဟု ယုံကြည်သောကြောင့်ဖြစ်သည်။ ထို့ကြောင့်၊ developer များသည် ဒေသအလိုက် တစ်ခုခုကို လုပ်ဆောင်ခြင်းနှင့် စမ်းသပ်ခြင်းထက် ကုဒ်နှင့် စိတ်ဝင်စားဖွယ်အရာများကို ရေးသားခြင်းထက် အချိန်ပိုပေးနိုင်သည်။

စဉ်ဆက်မပြတ် ပေါင်းစည်းခြင်းကို လေ့ကျင့်ပါ။ ဒါပေမယ့် ထိန်းညှိပေးတယ်။

စကားမစပ်၊ Nikolai Nesterov သည် သူ့ကိုယ်သူ ကောင်းမွန်သော အစီရင်ခံစာများကို ပေးရုံသာမက ပရိုဂရမ် ကော်မတီ၏ အဖွဲ့ဝင်လည်း ဖြစ်သည်။ AppsConf သင့်အတွက် အဓိပ္ပါယ်ရှိသော မိန့်ခွန်းများကို အခြားသူများအား ကူညီပြင်ဆင်ပေးပါသည်။ လာမည့်ကွန်ဖရင့်အစီအစဉ်၏ ပြီးပြည့်စုံမှုနှင့် အသုံးဝင်မှုကို ခေါင်းစဉ်များဖြင့် အကဲဖြတ်နိုင်ပါသည်။ အချိန်ဇယား. အသေးစိတ်အချက်အလက်များအတွက် ဧပြီလ 22-23 ရက်နေ့ထုတ် Infospace သို့ လာပါ။

source: www.habr.com