Prinsip-prinsip ini didasarkan pada metodologi terkenal dari heroku , disesuaikan dengan realitas pengembangan Ayios (Kurangnya wadah, ulasan yang memakan waktu beberapa hari dan memperlambat penyebaran, Xcode hanya bekerja pada poppy).
Artikel ini adalah pengantar singkat, seri lengkap dapat ditemukan pada faktor-iOS , terjemahan Rusia juga tersedia. Proyek open source iOS-factor di github terus disempurnakan dan menyambut ide-ide baru. Saya juga ambil bagian dalam pengembangannya. Proyek ini didirikan oleh Felix yang merupakan pencipta fastlane .
TL; DR
- Dependensi : Harus ditentukan secara spesifik dan spesifik (versi Xcode, CocoaPods, versi dependensi dalam podfile). Ini memungkinkan pengembang baru untuk memainkan build di Mac apa pun. Ulangi juga perakitan yang digunakan 6 bulan lalu.
- Konfigurasi : Tidak ada konfigurasi dalam kode, dilengkapi dengan aplikasi dan kemampuan untuk memperbarui melalui udara
- Pengembangan aplikasi / paritas kerja : Jaga agar lingkungan pengembangan, pementasan, dan produksi serata mungkin
- Deployment : Mengotomatiskan penerapan sehingga Anda dapat melepaskannya dari mesin apa pun.
- Lokal versus Beck : Jadikan aplikasi iOS Anda universal sehingga Anda dapat bekerja tanpa backend jika memungkinkan
- Backward Compatible APIs : Jangan Berpikir Setiap Pengguna Meng-upgrade ke Versi Terbaru
- Versi aplikasi : Versi otomatis dan peningkatan versi
- Kembalikan : perakitan kembalikan yang menyebabkan masalah
- Penyimpanan Data : Ikuti rekomendasi Apple untuk penyimpanan data
Aplikasi mendeklarasikan semua dependensinya secara lengkap dan akurat menggunakan manifes deklarasi dependensi.
Ini termasuk versi spesifik Swift, Xcode, CocoaPods, Carthgae, dan Fastlane. Juga, semua dependensi di podfile dan cartfile harus menentukan versi tertentu.
Salah satu keuntungan dari mendeklarasikan dependensi secara eksplisit adalah membuatnya mudah untuk mengkonfigurasi aplikasi untuk pengembang baru.
Dengan bantuan menentukan dependensi tertentu, Anda dapat mereproduksi build yang digunakan 6 bulan lalu, mengetahui bahwa itu akan dibangun karena build akan menggunakan versi Xcode, CocoaPods, dan Swift yang sama.
Batasan - Karena pengembangan iOS tidak dapat dimuat dalam wadah, karena sudah digunakan untuk pengembangan web, kami terbatas pada alat pihak ketiga yang mencoba memenuhi persyaratan ini sampai Apple memberikan solusi resmi. Ada solusi komersial pihak ketiga (tertutup) yang disebut Veertu yang memungkinkan Anda untuk membuat lingkungan MacOS virtual pada perangkat keras Apple.
Kode tidak tergantung pada lingkungan, tetapi konfigurasi tergantung. Oleh karena itu, kode tersebut harus disimpan dalam repositori, dan konfigurasi di lingkungan. Memeriksa apakah konfigurasi dan kode aplikasi dipisahkan dengan benar adalah fakta bahwa basis kode aplikasi dapat diakses secara bebas kapan saja tanpa mengorbankan data pribadi apa pun.
Ada banyak cara untuk memasukkan nilai konfigurasi selama perakitan.
- File Konfigurasi (File JSON atau YAML)
- cocoapods-keys untuk menyembunyikan kunci dan menerapkannya ke aplikasi iOS Anda selama pembuatan
- Solusi khusus (mis. Menggunakan fase bangun)
Karena penyebaran di platform iOS jauh lebih lambat daripada di server, Anda mungkin perlu cara untuk memperbarui konfigurasi over the air (OTA) untuk merespons masalah dengan cepat.
Pembaruan konfigurasi OTA memungkinkan Anda untuk secara instan:
- Jalankan tes A / B untuk mengaktifkan fungsi tertentu atau perubahan antarmuka pengguna hanya untuk sebagian pengguna aktif.
- Ubah kunci API
- Perbarui host web atau URL lain yang telah berubah
- Nonaktifkan fitur jarak jauh atau sembunyikan tombol
Beberapa pendekatan potensial ketika menerapkan pembaruan OTA adalah:
Secara historis, ada perbedaan yang signifikan antara pengembangan (pengembang membuat perubahan langsung pada penyebaran lokal aplikasi) dan pengoperasian aplikasi (penerapan aplikasi di App Store dengan akses ke sana oleh pengguna akhir).
Perbedaan-perbedaan ini muncul dalam tiga bidang:
- Perbedaan waktu
- Perbedaan staf
- Kesenjangan alat:
Solusi:
- Buat perbedaan waktu kecil: pengembang dapat menulis kode, dan itu akan digunakan dalam beberapa jam atau bahkan beberapa menit.
- Buat perbedaan staf kecil: pengembang yang menulis kode berpartisipasi secara aktif dalam penerapannya dan memantau perilakunya saat aplikasi sedang berjalan.
- Buat perbedaan alat kecil: jaga agar pengembangan aplikasi dan lingkungan kerja Anda seramai mungkin.
Sebagaimana dijelaskan dalam prinsip Dependensi , repositori kode harus mencakup semua dependensi yang diperlukan untuk membuat, menguji, dan menggunakan aplikasi iOS.
Sayangnya, karena fakta bahwa Xcode harus bekerja pada MacOS, kami tidak dapat menggunakan wadah seperti di web. Menjalankan macOS di lingkungan virtual penuh dengan masalah teknis dan hukum.
Saat ini, pendekatan terbaik yang dapat digunakan oleh pengembang iOS adalah:
Banyak perusahaan menggunakan konsep kereta Release: jadwal yang merilis versi baru aplikasi Anda. Semua kode yang digabung dengan cabang utama Anda (master atau rilis) saat kereta rilis "daun" akan dikirim ke App Store. Pendekatan ini diterapkan oleh sebagian besar aplikasi iOS besar.
Dalam beberapa tahun terakhir, beberapa tim pengembangan telah mulai menggunakan pendekatan yang membutuhkan upaya pengembangan lebih sedikit dengan menurunkan kualitas pengalaman pengguna, mentransfer lebih banyak logika ke backend dan menjadikan aplikasi iOS klien tipis yang menunjukkan hasil server.
Aplikasi harus melakukan logika bisnis dan komputasi pada perangkat sebanyak mungkin karena sejumlah alasan:
- Kerahasiaan: Hindari mengirim data ke server jauh
- Kecepatan: mengirim data ke server dan menunggu respons membutuhkan waktu dan dapat menyebabkan kerusakan (misalnya, WiFi yang buruk)
- Penggunaan data: pengguna sering memiliki batasan data bulanan
- Penskalaan: Jika aplikasi Anda menjadi populer, Anda bertanggung jawab untuk meningkatkan layanan backend.
- Battery Life: Ponsel itu mahal
- Keandalan: Koneksi LTE / 3G masih buruk di beberapa negara
Jika aplikasi Anda memerlukan koneksi Internet untuk semua fungsionalitas (misalnya, aplikasi jejaring sosial atau aplikasi berbagi perjalanan), aplikasi itu harus tetap berfungsi (dalam mode hanya baca) tanpa koneksi Internet untuk mengakses data historis (misalnya, baru-baru ini perjalanan, komunikasi langsung terbaru).
Meskipun sebagian besar pengguna Anda akan diperbarui ke versi terbaru dalam beberapa minggu, akan selalu ada pengguna yang tidak. Ini mungkin memiliki beberapa alasan. Seringkali ini karena versi iOS yang digunakan, yang tidak selalu dapat mereka perbarui karena usia perangkat.
Konsep dasarnya adalah Anda tidak memperbarui API yang ada, melainkan menambahkan yang baru dan membiarkannya bekerja secara paralel
https://your-api.com/1.0/drivers.json https://your-api.com/1.1/drivers.json
Versi dan nomor build digunakan bersama untuk mengidentifikasi aplikasi tertentu di aplikasi.
- Nomor Versi
(CFBundleShortVersionString) - (CFBundleShortVersionString) sebagai Versi dalam Xcode - Build Number
(CFBundleVersion) - (CFBundleVersion) sebagai Build in Xcode
Dalam pengembangan iOS saat ini, tidak ada alasan mengapa Anda harus mengubah angka-angka ini secara manual. Alih-alih, Anda memerlukan sistem yang andal dan otomatis untuk memperbarui versi.
Xcode memiliki alat bawaan yang disebut agvtool .
App Store pada awalnya tidak mengizinkan rollback, jadi bagian ini menjelaskan cara mencapai hasil yang serupa menggunakan metode yang tersedia.
Rilis tonggak sejarah - Menggunakan rilis tonggak, Anda dapat secara perlahan meluncurkan unit ke prod, dimulai dengan sejumlah kecil pengguna aktif
Namun, bahkan dalam kasus rilis bertahap, tidak mungkin untuk benar-benar memanggil kembali rakitan: setelah rakitan dipasang pada perangkat pengguna, satu-satunya cara untuk mengubah rakitan ini adalah mendistribusikan versi baru dengan versi / nomor versi yang diperbarui.
Seperti rilis bertahap, rakitan App Store dan TestFlight hanya dapat diperbarui dengan mengikuti langkah-langkah ini:
- Kembali ke sistem kontrol versi Anda ke keadaan yang ingin Anda putar kembali
- Tingkatkan versi dan / atau nomor bangun proyek Anda
- Buat dan tandatangani aplikasi Anda
- Distribusikan aplikasi Anda melalui layanan beta atau App Store
- Pengguna harus memperbarui aplikasi di teleponnya.
Langkah-langkah di atas dapat dilakukan secara manual, namun disarankan agar proses sepenuhnya otomatis agar dapat merespon dengan cepat.
Alternatif: tandatangani kembali bangunan lama
- Akses perakitan lama (file .ipa) sebelum regresi diperkenalkan
- Perbarui versi / nomor build dalam file Info.plist
- "Masuk lagi" bangunan lama
- Mendistribusikannya sebagai bangunan baru
Namun, "menandatangani" aplikasi iOS sering menimbulkan lebih banyak masalah, terutama karena alat baris perintah Xcode tidak menawarkan cara yang baik untuk melakukan ini.
Menyimpan data dan konfigurasi sesuai dengan rekomendasi Apple sangat penting untuk siklus hidup aplikasi Anda, khususnya ketika menyangkut sinkronisasi iCloud, peningkatan ke ponsel baru, dan memulihkan ponsel Anda dari cadangan.
Pastikan untuk mengikuti Pedoman Penyimpanan Data Apple iOS resmi:
Documents : Gunakan direktori ini untuk konten khusus, itu akan diarsipkanCaches : Gunakan direktori ini untuk data yang dapat dipulihkan.tmp : Gunakan direktori ini untuk file sementara- Gunakan properti
do not back up file
Jangan pernah menyimpan informasi rahasia pengguna (seperti kata sandi atau sesi) di direktori ini. Gunakan API Keychain sebagai gantinya.