თქვი შენი გამოცდილების შესახებ Release Candidate (RC)-თან მუშაობაში, როგორ გამოიყენე ეს მიდგომა შენი პროექტებში?

მე გამოვიყენე Release Candidate როგორც საბოლოო ტესტირების ფაზა, სანამ ის გამოქვეყნდება App Store-ში.

პროცესი ჩვეულებრივ მოიცავდა:

1. RC-ის შექმნა release ან main ფილიალზე სტაბილიზაციის შემდეგ.
2. ბილდის ატვირთვა TestFlight-ში ინტერნალური და/ან ექსტერნალური ბეტა ტესტერებისთვის.
3. დეტალური ტესტირება სხვადასხვა მოწყობილობებზე და iOS ვერსიებზე.
4. მხოლოდ კრიტიკული შეცდომების გამოსწორება, რომლებიც აფერხებდნენ გამოშვებას. მცირე გაუმჯობესებები და კრიტიკული არამნიშვნელოვანი შეცდომები გადადიოდა შემდეგ ვერსიებზე.
5. თუ აღმოაჩენთ კრიტიკულ შეცდომებს: შექმენით პაჩ-ფილიალი RC-დან, გამოსწორება, ახალი RC-ის შექმნა და ნაბიჯების 1-4 გამეორება.
6. თუ RC წარმატებით გადის ტესტებს და არ შეიცავს კრიტიკულ შეცდომებს: იგივე ბილდის გამოქვეყნება App Store-ში.

RC-ის გამოყენება მინიმუმამდე էր բերում անկայուն տարբերակի թողարկების ռისკը, რადგან փորձისთვის გამოყენებული ბილდი იყო იგივე, რაც საბოლოო მომხმარებლებს მიეწოდებოდა. ეს ზრდიდა გამოშვების ხარისხის მიმართ վստահობას.