Plugin Gradle Android Kotlin Extensions (jangan disamakan dengan Android KTX) dirilis pada tahun 2017 dan menghadirkan dua kemudahan baru untuk pengembangan Android di Kotlin:
Sejak saat itu, kami telah merilis View Binding for Android, library dengan dukungan resmi yang memiliki integrasi mendalam dengan toolchain build Android dan menyediakan fungsi yang serupa dengan synthetic Kotlin. Meskipun kami terus merekomendasikan Parcelize, sejumlah kelemahan muncul saat menggunakan synthetic Kotlin:
JetBrains awalnya mengembangkan plugin Android Kotlin Extensions, dan kami semua telah membahas kelebihan dan kekurangan dari terus mempertahankan synthetic: kami berusaha keras untuk menjamin dukungan jangka panjang untuk API, tetapi kami juga ingin membimbing developer menuju praktik terbaik yang membuat basis kode yang baik, pada akhirnya, pengguna yang senang.
Tahun depan, tim kami akan bersama-sama menghentikan penggunaan synthetic untuk terus mendukung opsi yang kami rekomendasikan, View Binding. Inilah artinya:
Periode penghentian dimulai dengan Kotlin 1.4.20, yang dirilis hari ini. android-kotlin-extensions akan terus ada setidaknya selama satu tahun, tetapi akan dihapus pada rilis Kotlin mendatang selama atau setelah September 2021. Untuk jangka panjang, kami akan terus mempertahankan plugin kotlin-parcelize, dan Anda bisa terus melaporkan masalah Parcelize di issue tracker Android Studio.
Sejak mengumumkan dukungan Kotlin pada tahun 2017, kami mendapatkan banyak pertanyaan tentang Kotlin di Android: Anda ingin tahu apakah sudah waktunya mempelajari Kotlin, menghadirkannya ke aplikasi Anda, kursus atau tutorial apa yang terbaik untuk mempelajarinya, apakah Google secara internal menggunakan Kotlin dan rencana kami untuk bahasa pemrograman Java. Dalam postingan kali ini, saya akan menjawab beberapa pertanyaan berikut.
Pertanyaan serupa yang paling sering kami terima adalah:
Jawaban singkat:
Ya! Mulailah pelajari dan gunakan Kotlin!
Jawaban panjang:
Pada tahun 2017, kami mengumumkan dukungan Kotlin di Google I/O. Saat itulah kami mulai membuat langkah pertama untuk memastikan bahwa API, dokumen, dan contoh kami ramah-Kotlin. Pada tahun 2019, Android mulai mengutamakan Kotlin, jadi kami lebih mengandalkan fitur Kotlin. Sebagai contoh, Coroutine menjadi solusi yang kami rekomendasikan untuk menjalankan pekerjaan asinkron. Inilah hal lain yang telah kami lakukan:
Kami mulai dengan menambahkan dukungan kelas satu untuk Coroutine Kotlin ke beberapa Android Jetpack API kami, seperti Room, LiveData, ViewModel, dan WorkManager, hal ini mengubah cara kami melakukan operasi asinkron di Android. Firebase Android SDK dan banyak library Jetpack memiliki library ekstensi Kotlin (KTX) agar penggunaannya lebih lancar dengan Kotlin.
Sekarang, banyak library kami yang mengutamakan Kotlin, seperti Paging 3.0 dan DataStore. Jetpack Compose, toolkit UI deklaratif terpisah kami yang baru, ditulis dari awal dengan Kotlin.
Produktivitas pengembangan berawal dari peralatan yang tepat. Karena itu, kami telah melakukan banyak peningkatan untuk Kotlin pada toolchain kompilasi, termasuk penyempurnaan compiler JVM Kotlin, pengoptimalan R8 khusus Kotlin, bahkan mengembangkan alat baru seperti Kotlin Symbol Processing. Kami telah menambahkan template Android Kotlin Live bawaan, sehingga Anda bisa menggunakan cara pintas untuk menambahkan konstruksi Android umum ke aplikasi Kotlin. Pada saat yang sama, pemeriksaan Lint khusus Kotlin membantu Anda membuat kode Kotlin lebih idiomatis. Ini sangat berguna saat Anda beralih dari bahasa pemrograman Java ke Kotlin.
Kami juga melipatgandakan Kotlin di Google. Lebih dari 60 aplikasi kami (seperti Google Home, Drive, Maps, dan lainnya) telah menambahkan Kotlin ke codebase aplikasi. Codebase internal besar kami menghitung lebih dari dua juta baris kode Kotlin.
Kami sering mendapatkan pertanyaan ini, tetapi jawabannya tergantung Anda. Jika Anda sudah senang dengan codebase dan tech stack saat ini, pintar mencari solusi untuk mengelola tugas asinkron, dan memiliki cara yang efisien untuk menangkap kesalahan, migrasi mungkin bukan solusi untuk Anda
Jika Anda menyukai apa yang telah Anda lihat dengan Kotlin baik dengan mencobanya maupun mempelajari bahasanya melalui beberapa kursus yang disebutkan di bawah, dan Anda juga ingin memanfaatkan Jetpack API terbaru, maka Anda harus mempertimbangkan untuk menambahkan Kotlin ke aplikasi. Salah satu keuntungan Kotlin adalah interop yang sangat bagus dengan bahasa pemrograman Java. Anda bisa mengambil langkah kecil secara bertahap dalam mengadopsinya — mungkin terlebih dahulu mencobanya di pengujian, lalu mencoba beberapa fitur baru, kemudian Anda dapat mencoba konversi beberapa kode lama saat menyentuhnya.
Untuk membuat langkah pertama Anda dalam migrasi ke Kotlin idiomatis, lihat Mengonversi ke codelab Kotlin.
Kami menambahkan dukungan Kotlin selain Java karena keduanya dikompilasi ke bytecode yang sama dan bisa berdampingan satu sama lain. Kami menyukai Kotlin karena ekspresif dan lebih aman saat menulis kode. Kami juga terus mempertahankan dan mengembangkan dukungan Java. Misalnya, di Android 11, kami menambahkan dukungan untuk sejumlah API dari rilis OpenJDK terbaru hingga versi 13 dan Android Studio bahkan mengizinkan Anda menggunakan beberapa API ini di semua perangkat Android, apa pun versi OS-nya. Baca selengkapnya tentang dukungan untuk API bahasa terbaru di sini.
Mengadopsi bahasa baru bukanlah tugas yang mudah, tetapi kami berusaha membuatnya semudah mungkin:
Sejak secara resmi menambahkan dukungan untuk Kotlin 3 tahun lalu, kami semakin meningkatkan dukungan untuk bahasa dan ekosistem yang luar biasa ini. Bersama JetBrains, kami telah membangun fondasi bagi Kotlin untuk memastikan bahasanya berkembang dengan baik, misalnya melalui proses yang cermat untuk memeriksa perubahan yang dapat menyebabkan gangguan. Kontribusi kami lebih dari itu: Google memiliki tim engineer yang berkontribusi untuk compiler Kotlin sebagai pekerjaan tetap mereka, Jetpack API yang kami bangun tidak hanya mendukung Kotlin tetapi juga mengutamakan Kotlin, dan kami berkomitmen untuk memberikan pengalaman Kotlin yang mulus di Android.
Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Selamat datang di Now in Android, panduan berkelanjutan Anda tentang apa yang baru dan penting dalam dunia development Android.
Seri MAD Skills terus berlanjut, dengan konten teknis tentang development Android modern. Wojtek Kaliciński dan Ben Weiss telah memposting beberapa episode pada seri kedua di App Bundle. Sejauh ini, kami telah melihat konten Play App Signing, Building your First App Bundle, dan Play Feature Delivery. Lihat video dan artikel di bawah ini untuk mengetahui selengkapnya.
Dalam seri tentang Android App Bundle, kita sering membicarakan tentang penandatanganan aplikasi, karena Play menghasilkan APK untuk didownload ke perangkat pengguna, dan APK tersebut harus ditandatangani agar bisa diinstal. Video ini akan memperlihatkan kepada Anda cara mengaktifkan penandatanganan aplikasi di Konsol Play, termasuk opsi untuk meminta Google membuat kunci atau meng-upload kunci Anda sendiri.
Pastikan membaca artikel terkait dari Wojtek mengenai pertanyaan umum tentang Play App Signing:
Jawaban atas pertanyaan umum tentang App Signing dari Google Play
Video dari Ben akan membimbing Anda melalui langkah-langkah pembuatan App Bundle, Anda bisa melakukannya di Android Studio atau baris perintah, dilanjutkan dengan meng-upload-nya ke Konsol Play. Ia juga menunjukkan cara menggunakan alat di Konsol Play untuk menggali informasi tentang paket yang di-upload.
Episode ini menunjukkan kepada Anda cara menggunakan Android Studio untuk memodularisasi aplikasi, dan cara memilih modul yang akan didownload pada waktu penginstalan (dengan kondisi opsional yang menentukan apakah akan diinstal atau tidak) atau sesuai permintaan. Ben juga menjelaskan secara detail cara menggunakan API untuk meminta penginstalan modul sesuai permintaan.
Atau dalam bentuk artikel:
Mengonfigurasi aplikasi Anda untuk Play Feature Delivery
Dalam episode terakhir ini, Wojtek menjelaskan cara menggunakan alat yang tersedia untuk menguji bundel Anda dan APK yang dihasilkan, termasuk bundletool untuk pengujian lokal serta Konsol Play untuk menguji upload.
Ada beberapa artikel dan dokumen yang ditautkan dari deskripsi video, pastikan memeriksanya untuk mendapatkan informasi lebih lanjut tentang topik tersebut.
Nantikan konten App Bundle final minggu depan, kami akan mengadakan sesi Tanya Jawab langsung Kamis mendatang (link YouTube live akan muncul di playlist saat sesi dimulai, dan kami akan mengirimkan pesan sebelum acara berlangsung bila Anda punya pertanyaan).
Untuk konten yang berlangsung, pastikan memeriksa playlist MAD Skills di YouTube, artikel di Medium, atau halaman pendahuluan praktis ini yang akan menunjukkan semuanya. Seri berikutnya akan dimulai minggu depan: nantikan informasi selanjutnyanya!
Di tengah banyaknya rilis alfa, beta, dan RC inkremental dari library AndroidX, ada beberapa versi stabil penting yang baru saja diluncurkan dan harus Anda perhatikan.
Kita tidak selalu membicarakan Kotlin, tetapi ketika kita melakukannya, kita akan banyak membicarakannya. Ada beberapa artikel dan video yang diposting tentang Kotlin baru-baru ini:
Florina Muntenescu menambahkan episode lain dalam seri Kotlin Vocabulary yang sedang berjalan, kali ini tentang class data Kotlin. Class data memungkinkan Anda membuat struktur dengan mudah untuk menyimpan data dengan kode boilerplate lebih sedikit, dan mengandalkan Kotlin untuk secara otomatis menghasilkan fungsi equals() dan hashCode() yang sesuai. Anda juga langsung mendapatkan destrukturisasi untuk properti class, bersama dengan copy(). Seperti biasa untuk episode Kotlin Vocabulary, Florina mendalami bytecode yang telah didekompilasi untuk class data guna menjelaskan cara kerjanya.
Class data — cara berkelas untuk menyimpan data
Berbicara tentang Kotlin Vocabulary, Murat Yener memposting lanjutan dari artikel sebelumnya tentang fitur delegate Kotlin. Kali ini, ia akan membahas tentang delegate yang disediakan oleh Kotlin Standard Library: lazy, observable, vetoable, dan notNull.
Delegate Bawaan
Jawaban singkatnya adalah… Ya!
Namun untuk penjelasan lebih panjang, Florina memposting artikel ini untuk menjawab beberapa pertanyaan yang sering diajukan developer tentang berinvestasi dalam pendidikan dan development Kotlin, serta link ke sumber daya pembelajaran penting.
Haruskah saya mempelajari Kotlin untuk Android dan Tanya Jawab lainnya
Dalam artikel ini, Florina membahas beberapa alasan yang membuat aplikasi Kotlin tidak rentan error dibandingkan aplikasi yang tidak ditulis dengan Kotlin. Ia menunjukkan beberapa aplikasi dan kasus penggunaan tertentu yang mendukung pernyataan ini, tetapi juga membahas beberapa alasan mengapa bahasa ini memungkinkan kode menjadi lebih kuat, termasuk nullability, hashCode() != equals(), dan lainnya. Baca postingannya untuk mengetahui semua detailnya.
Error berkurang dan stabilitas bertambah dengan Kotlin
Ada episode lain dari Android Developers Backstage yang diposting sejak Now in Android terakhir. Lihatlah pada link di bawah ini, atau di klien podcast favorit Anda:
Romain Guy, Tor Norbye, dan saya berbicara dengan Colin White dari Instacart tentang library pemuatan gambar sumber terbuka, Coil. Kami mengobrol tentang pemuatan gambar, kinerja, sumber terbuka, dan penggunaan Kotlin serta coroutine untuk membuat library yang mengutamakan Kotlin ini.
Episode 151: Pemuatan Gambar dengan Coil
Cukup sampai di sini. Jadi, silakan pelajari App Bundle! Download rilis AndroidX terbaru! Baca artikel terbaru tentang Kotlin! Dengarkan episode podcast ADB terbaru! Dan segera kembali ke sini untuk mendapatkan update berikutnya dari dunia developer Android.
Oleh Andrew Ahn, Product Manager, Google Play App Safety
Di Google Play, kami ingin mengembangkan ekosistem aplikasi yang aman, menarik, berguna, dan menghibur yang digunakan dan disukai oleh miliaran pengguna Android di seluruh dunia. Itulah sebabnya kami secara rutin mengupdate dan merevisi Kebijakan Developer dan Perjanjian Distribusi Developer Google Play, memerinci batasan konten dan fungsi aplikasi yang diizinkan pada platform, serta memberikan panduan terbaru tentang cara developer mempromosikan dan memonetisasi aplikasi.
Pada upaya terbaru dalam menganalisis aplikasi mengenai kepatuhan kebijakan di Google Play, kami mengidentifikasi beberapa kesalahan dan pelanggaran yang sering dilakukan developer, dan kami membagikannya dengan komunitas developer dengan tips dan panduan tentang cara menghindarinya, mengurangi risiko aplikasi dan akun developer ditangguhkan karena melanggar kebijakan kami.
Salah satu kesalahan yang paling sering kami lihat adalah aplikasi yang memiliki tombol dan menu yang terhubung ke Play Store -- baik ke aplikasi oleh developer yang sama, atau aplikasi lain yang mungkin berafiliasi dengan developer tersebut, tetapi tidak jelas apakah ini iklan atau link promosi. Tanpa kejelasan ini, aplikasi mungkin akan dipaksa memiliki iklan yang memperdaya / mengecoh. Salah satu cara menghindari kesalahan ini adalah dengan secara eksplisit memanggilnya dengan memberi label pada tombol dan link dengan ‘Aplikasi Lainnya’, ‘Game Lainnya’, ‘Jelajahi’, ‘Lihat aplikasi kami yang lainnya’, dll.
Contoh konten aplikasi yang terhubung ke cantuman aplikasi di Play
Kesalahan lain yang sering kami temui adalah developer yang ‘memasukkan’ kata kunci dalam keterangan aplikasi dengan harapan menghasilkan visibilitas dan peringkat yang lebih baik terhadap kata kunci dan frasa tertentu. Blok atau daftar teks yang berisi kata kunci atau referensi berulang atau tidak terkait melanggar kebijakan Cantuman Play Store dan Promosi kami. Menulis keterangan aplikasi dengan jelas yang ditujukan dan dioptimalkan agar mudah dibaca dan dipahami pengguna adalah salah satu cara terbaik untuk menghindari pelanggaran ini.
Tonton video ini untuk mempelajari cara menghindari cantuman toko berisi spam dan upaya meningkatkan visibilitas aplikasi secara artifisial.
Ada aplikasi yang sudah lama dipublikasikan oleh developer, tetapi tidak lagi dikelola. Aplikasi yang terbengkalai dan tidak dikelola sering kali menimbulkan masalah pengalaman pengguna -- misalnya, fungsi aplikasi rusak. Aplikasi semacam itu tidak hanya berisiko mendapatkan rating bintang rendah dan ulasan negatif dari pengguna, tetapi juga akan ditandai karena melanggar kebijakan fungsi minimum. Untuk mengurangi dampak negatif terhadap reputasi developer dan pemaksaan aplikasi, sebaiknya batalkan publikasi aplikasi tersebut dari Play Store. Perhatikan bahwa tindakan pembatalan publikasi yang diupdate tidak akan memengaruhi pengguna lama yang telah menginstal aplikasi, dan developer selalu bisa memilih untuk memublikasikannya kembali setelah memperbaiki pengalaman yang rusak.
Contoh aplikasi terbengkalai yang memberikan pengalaman aplikasi rusak
Ikuti kursus ‘Minimum and Broken Functionality Spam’ di Akademi Play
Terakhir, kami memperhatikan banyak sekali pengajuan aplikasi yang hanya merupakan webview dari situs yang ada. Sebagian besar aplikasi ini dikirimkan dengan tujuan utama untuk mengarahkan traffic, bukan memberikan pengalaman aplikasi yang menarik kepada pengguna Android. Aplikasi semacam ini dianggap sebagai spam webview, dan dihapus dari Play. Sebagai gantinya, pikirkan apa yang bisa dilakukan pengguna atau yang bisa dilakukannya lebih baik dengan menggunakan aplikasi daripada di web dan terapkan fitur serta fungsi relevan yang memperkaya pengalaman pengguna.
Contoh webview tanpa fungsi aplikasi
Ikuti kursus ‘Webview Spam’ di Akademi Play
Meskipun hal di atas adalah salah satu kesalahan yang paling sering terjadi, pastikan selalu mengikuti kebijakan terbaru dengan mengunjungi Pusat Kebijakan Developer Play. Lihat pelatihan Kebijakan Akademi Google Play, termasuk kursus Spam baru kami, dan tonton video Play PolicyBytes kami untuk mempelajari lebih lanjut tentang update kebijakan terbaru.
Diposting oleh Scott Swarthout, Product Manager
Hari ini, kami gembira bisa merilis versi stabil Android Studio 4.1, dengan rangkaian fitur yang ditujukan untuk menangani kasus penggunaan pengeditan, proses debug, dan pengoptimalan. Tema utama rilis ini adalah menjadikan Anda lebih produktif saat menggunakan library Android Jetpack, suite library Android untuk membantu developer mengikuti praktik terbaik dan menulis kode dengan lebih cepat. Berdasarkan masukan Anda, kami membuat sejumlah peningkatan pada cara pengeditan kode dengan integrasi IDE untuk library Android populer.
Beberapa sorotan Android Studio 4.1 termasuk Database Inspector baru untuk membuat kueri database aplikasi Anda, dukungan perencanaan project yang menggunakan Dagger atau Hilt untuk memasukkan dependensi, dan dukungan yang lebih baik untuk machine learning di perangkat dengan dukungan bagi model TensorFlow Lite di project Android. Kami juga telah memperbarui Apply Changes untuk mempercepat penerapan. Berdasarkan masukan Anda, kami telah melakukan beberapa perubahan untuk membantu developer game dengan alat pemrofilan mandiri dan profiler memori native yang baru.
Kualitas produk terus menjadi fokus utama tim, dan kami terus bekerja keras untuk melacak bug dan masalah performa. Kami mendengar dari banyak developer bahwa mereka menyukai fokus pada performa dan keandalan yang lebih baik, jadi dengan gembira kami laporkan bahwa selama siklus rilis ini kami telah memperbaiki 2.370 bug dan menutup 275 masalah publik. Kami tetap commit untuk menjaga kualitas tinggi karena kami tahu bahwa ini adalah kunci produktivitas developer.
Terima kasih kepada Anda semua yang telah memberikan masukan awal dalam rilis pratinjau. Masukan Anda membantu kami melakukan iterasi dan meningkatkan fitur di Android Studio 4.1. Jika Anda siap untuk rilis stabil berikutnya, dan ingin menggunakan rangkaian fitur produktivitas baru, Android Studio 4.1 siap didownload untuk Anda memulai.
Berikut adalah daftar lengkap fitur baru di Android Studio 4.1, yang disusun menurut alur developer kunci.
Template Android Studio dalam dialog create New Project sekarang menggunakan Komponen Desain Material (MDC) dan secara default menyesuaikan dengan panduan terbaru tema dan gaya. Perubahan ini akan mempermudah penggunaan pola gaya material yang direkomendasikan dan mendukung fitur UI modern seperti tema gelap.
Update Komponen Desain Material di Template Project
Update meliputi:
com.google.android.material:material
Theme.MaterialComponents.*
colors.xml
purple_500
colorPrimary
themes.xml
styles.xml
Theme.<ApplicationName>
DayNight
?attr/colorPrimary
Kami ingin memudahkan pemeriksaan, kueri, dan modifikasi database aplikasi Anda menggunakan Database Inspector yang baru. Untuk memulai, terapkan aplikasi Anda ke perangkat yang menjalankan API level 26 atau yang lebih tinggi dan pilih View > Tool Windows > Database Inspector dari panel menu. Walaupun aplikasi Anda menggunakan library Jetpack Room atau versi platform Android SQLite secara langsung, Anda sekarang bisa dengan mudah memeriksa database dan tabel di aplikasi yang sedang berjalan atau menjalankan kueri khusus.
Karena Android Studio mempertahankan koneksi langsung saat Anda memeriksa aplikasi, Anda juga bisa mengubah nilai menggunakan Database Inspector dan melihat perubahan tersebut di aplikasi yang sedang berjalan. Jika Anda menggunakan library persisten Room, Android Studio juga menempatkan tombol run di samping setiap kueri dalam editor kode untuk membantu menjalankan kueri yang Anda tetapkan dalam anotasi @Query dengan cepat. Pelajari lebih lanjut
Periksa, kueri, dan modifikasi database aplikasi Anda dengan Database Inspector
Sekarang Anda bisa menjalankan Android Emulator secara langsung di Android Studio. Gunakan fitur ini untuk menghemat ruang layar, beralih antara emulator dan jendela editor dengan cepat menggunakan tombol pintas, dan mengatur alur kerja IDE dan emulator Anda dalam satu jendela aplikasi. Anda bisa mengelola snapshot dan tindakan emulator umum seperti memutar dan mengambil screenshot dari dalam Studio, tetapi akses ke rangkaian opsi lengkap tetap membutuhkan emulator stabil. Anda bisa memilih untuk menggunakan fitur ini dengan membuka File → Settings → Tools → Emulator → Launch in Tool Window.
Jalankan Android Emulator di dalam Android Studio
Dagger adalah library populer untuk memasukkan dependensi di Android. Android Studio memudahkan navigasi di antara kode yang terkait Dagger dengan menyediakan gutter tindakan baru dan memperluas dukungan di jendela Find Usages. Sebagai contoh, mengklik gutter tindakan di samping metode yang menggunakan tipe tertentu akan mengarahkan Anda ke penyedia tipe tersebut. Sebaliknya, mengklik gutter tindakan akan mengarahkan Anda ke tempat yang menggunakan tipe tersebut sebagai dependensi. Android Studio juga mendukung tindakan navigasi untuk dependensi yang ditetapkan dengan library Hilt Jetpack. Pelajari lebih lanjut.
Buka kode terkait Dagger dengan tindakan gutter
Developer Android menggunakan machine learning untuk menciptakan pengalaman yang inovatif dan bermanfaat. TensorFlow Lite adalah library populer untuk menulis model machine learning seluler, dan kami ingin memudahkan impor model ini ke dalam aplikasi Android. Serupa dengan binding tampilan, Android Studio menghasilkan kelas yang mudah digunakan sehingga Anda bisa menjalankan model dengan kode yang lebih sedikit dan keamanan tipe yang lebih baik. Penerapan ML Model Binding saat ini mendukung klasifikasi gambar dan model transfer gaya, asalkan mereka dilengkapi metadata.
Untuk melihat detail model yang diimpor dan mendapatkan petunjuk tentang cara menggunakannya di aplikasi, klik dua kali file model .tflite di project Anda untuk membuka halaman model viewer. Pelajari lebih lanjut.
.tflite
Lihat metadata model TensorFlow Lite di Android Studio 4.1
Android Studio
Selain baru-baru ini menambahkan dukungan pengujian seluler 5G, kami telah menambahkan dukungan untuk perangkat foldable di Android emulator. Dengan Android emulator 30.0.26 ke atas, Anda bisa mengonfigurasi perangkat foldable dengan berbagai desain dan konfigurasi lipatan. Bila perangkat foldable telah dikonfigurasi, emulator akan memublikasikan update sensor sudut engsel dan perubahan postur, sehingga Anda bisa menguji cara aplikasi merespons faktor bentuk ini. Lihat entri blog Develop untuk Android 11 dengan Android Emulator untuk membaca informasi selengkapnya.
Build yang lebih cepat membantu developer membuat perubahan pada aplikasi mereka dengan lebih mudah dan cepat. Agar Anda semakin produktif saat melakukan iterasi pada aplikasi, kami telah melakukan beberapa penyempurnaan pada Apply Changes untuk perangkat yang menjalankan Android 11 atau yang lebih tinggi.
Kami telah berinvestasi besar-besaran dalam mengoptimalkan kecepatan iterasi Anda dengan mengembangkan metode untuk menerapkan dan mempertahankan perubahan pada perangkat tanpa menginstal aplikasi. Setelah penerapan awal, penerapan berikutnya ke perangkat Android 11 yang menggunakan Apply Code Changes atau Apply Changes and Restart Activity sekarang jauh lebih cepat. Kami juga menambahkan dukungan untuk perubahan kode tambahan di Apply Changes. Sekarang jika menambahkan metode, Anda bisa menerapkan perubahan tersebut ke aplikasi yang sedang berjalan dengan mengklik Apply Code Changes atau Apply Changes and Restart Activity.
Plugin Android Gradle 4.0 menambahkan kemampuan untuk mengimpor paket Prefab dalam dependensi AAR. Kami juga ingin memperluas kemampuan fitur ini untuk mendukung berbagi library native. AGP versi 4.1 memungkinkan ekspor library dari build native eksternal Anda dalam AAR untuk project Android Library. Untuk mengekspor library native Anda, tambahkan kode berikut ke blok android dari file build.gradle project library:
build.gradle
buildFeatures { prefabPublishing true } prefab { mylibrary { headers "src/main/cpp/mylibrary/include" } myotherlibrary { headers "src/main/cpp/myotherlibrary/include" } }
Saat error atau ANR terjadi pada kode native, sistem menghasilkan pelacakan tumpukan, yang merupakan snapshot urutan fungsi yang dipanggil dalam program Anda hingga saat program tersebut error. Snapshot ini bisa membantu Anda mengidentifikasi dan memperbaiki masalah apa pun di sumbernya, tetapi mereka harus terlebih dahulu disimbolkan untuk menerjemahkan alamat mesin ke nama fungsi yang dapat dibaca manusia.
Jika aplikasi atau game Anda dikembangkan menggunakan kode native, seperti C++, Anda sekarang bisa mengupload file simbol debug ke Konsol Play untuk setiap versi aplikasi Anda. Konsol Play menggunakan file simbol debug ini untuk menyimbolkan pelacakan tumpukan aplikasi Anda, sehingga mempermudah analisis error dan ANR. Untuk menyertakan simbol debug dalam paket aplikasi, tambahkan baris berikut ke file build.gradle project Anda:
android.buildTypes.release.ndk.debugSymbolLevel = 'SYMBOL_TABLE'
Di Android Studio 4.1 kami telah merombak System Trace, alat pengoptimalan yang memberi Anda gambaran real-time tentang cara aplikasi menggunakan resource sistem. Kami mempermudah pemilihan trace dengan mode box selection, menambahkan tab analisis baru, dan menambahkan lebih banyak data rendering bingkai untuk membantu Anda menyelidiki masalah rendering di UI aplikasi. Pelajari lebih lanjut.
Pemilihan berbentuk kotak: Di bagian Threads, Anda sekarang bisa menarik mouse untuk melakukan pemilihan berbentuk kotak area persegi panjang, yang dapat Anda perbesar dengan mengklik tombol Zoom to Selection di kanan atas (atau menggunakan pintasan keyboard M). Saat Anda menarik lalu melepaskan thread serupa di samping thread lainnya, Anda bisa memilih beberapa thread untuk memeriksa semuanya sekaligus.
Gunakan pemilihan kotak agar lebih mudah memilih trace.
Tab Summary: Tab Summary baru di tampilan panel Analysis:
Lihat statistik gabungan di tab Summary
Data tampilan: Di bagian Display, timeline baru untuk SurfaceFlinger dan VSYNC membantu Anda menyelidiki masalah rendering di UI aplikasi.
Sekarang Anda bisa mengakses Android Studio Profiler di jendela terpisah dari jendela utama Android Studio. Ini berguna saat mengoptimalkan game Android yang dibuat dengan alat lain seperti Unity atau Visual Studio.
Untuk menjalankan profiler mandiri, lakukan langkah berikut:
Windows/Linux: <studio-installation-folder>\bin
<studio-installation-folder>\bin
macOS: <studio-installation-folder>/Contents/bin
<studio-installation-folder>/Contents/bin
profiler.exe
profiler.sh
Profiler mandiri memungkinkan Anda menghubungkan ke Android emulator atau perangkat apa pun yang terhubung.
Optimalkan aplikasi Anda dengan Profiler Mandiri Android Studio
Melacak penggunaan memori native sangatlah penting bagi developer game dan developer lain yang menggunakan C++ untuk memahami cara mengoptimalkan konsumsi memori aplikasi mereka. Android Studio Memory Profiler sekarang menyertakan Native Memory Profiler untuk aplikasi yang diterapkan ke perangkat fisik yang menjalankan Android 10 atau lebih baru. Native Memory Profiler melacak alokasi/dealokasi objek dalam kode native untuk jangka waktu tertentu dan memberikan informasi tentang alokasi total dan ukuran heap sistem yang tersisa.
Untuk memulai perekaman, klik Record native allocations di bagian atas jendela Memory Profiler:
Lihat alokasi memori native dengan Native Memory Profiler
Untuk rekap, Android Studio 4.1 menyertakan penyempurnaan & fitur baru ini:
Design
Develop
Build & Test
Optimize
Materi ini tidak disponsori atau berafiliasi dengan Unity Technologies atau afiliasinya. “Unity” adalah merek dagang atau merek dagang terdaftar dari Unity Technologies atau afiliasinya di A.S. dan negara lainnya.
Diposting oleh Steve Suppe, Product Manager, Google Play
Memublikasikan aplikasi atau game adalah salah satu momen terpenting dalam siklus hidup aplikasi Anda. Anda tentu menginginkan semuanya berjalan lancar, mulai dari memastikan rilis produksi yang stabil, meluncurkan rilis pengujian dengan cepat, hingga menyampaikan pesan pemasaran dengan tepat.
Karena itulah visibilitas adalah kuncinya. Anda bisa mengatur jadwal sendiri bila mengetahui kapan aplikasi sedang ditinjau, sudah disetujui, dan ditayangkan langsung di Google Play.
Sekarang, dengan dua fitur baru di Konsol Google Play baru, Anda bisa melakukannya. Halaman Ringkasan publikasi membantu Anda memahami proses publikasi dan Publikasi terkelola memberikan kontrol yang lebih baik mengenai kapan update aplikasi ditayangkan di Google Play. Saat Konsol Play baru diluncurkan untuk umum mulai 2 November, fitur ini akan menjadi cara yang direkomendasikan untuk mengontrol waktu rilis Anda, jadi mari kita lihat lebih dekat.
Ringkasan publikasi
Halaman Ringkasan publikasi baru menampilkan semua perubahan terbaru mengenai rilis, cantuman toko, dan lainnya, termasuk yang sedang ditinjau atau diproses oleh Google Play. Bagi Anda yang memiliki tim lebih besar, Anda sekarang bisa mengoordinasikan semua perubahan di satu tempat dan memublikasikan semuanya di waktu yang sama.
Tidak seperti log aktivitas developer, Ringkasan publikasi hanya menampilkan perubahan yang terlihat di Google Play, atau yang Anda informasikan kepada kami tentang cara mempertimbangkan dan meninjau aplikasi Anda.
Bagian “Perubahan sedang ditinjau” memungkinkan Anda dengan cepat melihat perubahan yang belum dipublikasikan.
Perubahan ini diatur menurut tipe perubahan atau jalur rilis sehingga mudah dipahami dalam sekejap.
Publikasi terkelola Banyak dari Anda mungkin sudah familier dengan Publikasi berwaktu di Konsol Play lama. Di Konsol Play baru, kami telah mengganti Publikasi berwaktu dengan Publikasi terkelola, untuk memberi Anda pengalaman publikasi yang lebih jelas dan lebih terprediksi.
Saat Anda mengaktifkan Publikasi terkelola, perubahan yang disetujui hanya akan ditampilkan saat Anda memutuskan, bukan otomatis setelah ditinjau dan diproses. Ini memungkinkan Anda untuk mengirimkan perubahan jauh sebelum tanggal rilis yang direncanakan, sehingga memberi Anda waktu untuk meninjau atau membuat perubahan tanpa mengorbankan tanggal publikasi.
Lihat perubahan yang telah ditinjau dan disetujui
Saat Publikasi terkelola aktif, halaman Ringkasan publikasi berisi dua bagian: satu bagian menampilkan perubahan yang telah disetujui dan siap dipublikasikan, dan satu bagian lagi menampilkan perubahan yang masih ditinjau.
Kami juga telah membuat beberapa penyempurnaan yang banyak diminta oleh Anda sekalian:
● Sekarang Anda bisa memublikasikan perubahan yang Anda setujui meskipun perubahan lain masih ditinjau. Sebelumnya, Publikasi berwaktu tidak mengizinkan Anda melakukan perubahan apa pun hingga semua perubahan disetujui.
● Anda bisa mengaktifkan atau menonaktifkan Publikasi terkelola kapan saja, bahkan jika ada perubahan yang sedang ditinjau atau siap dipublikasikan. Anda tidak perlu lagi menunggu tinjauan yang tertunda sebelum Anda bisa menggunakan Publikasi terkelola.
Lihat apakah Publikasi terkelola diaktifkan di menu navigasi sebelah kiri
Setelah itu, Anda dapat melihat ikon Publikasi terkelola di navigasi sebelah kiri di samping Ringkasan publikasi. Dengan cara ini, Anda bisa mengetahui bahwa Publikasi terkelola aktif dari mana pun di Konsol Play.
Untuk mempelajari lebih lanjut tentang publikasi dengan Konsol Play baru, termasuk skenario ketika fitur-fitur ini akan sangat berguna, lihat kursus ini dariPlay Academy. Dan jika Anda belum melakukannya, update ke Konsol Play baru di play.google.com/console dan cobalah Publikasi terkelola.
Migrasi ke cloud untuk enterprise yang telah menjalankan beban kerja secara lokal selama bertahun-tahun bukanlah hal yang mudah. Agar berhasil, rencana migrasi perlu mempertimbangkan berbagai aspek yang berkaitan dengan manusia, proses, dan teknologi. Jika mendesain migrasi, Anda membutuhkan panduan dan praktik terbaik untuk membantu memandu Anda melalui proses ini.
Berdasarkan pengalaman sebagai arsitek solusi, kami telah mengumpulkan dokumen lengkap untuk praktisi TI yang merencanakan, mendesain, dan mengimplementasikan migrasi ke Google Cloud. Di halaman Migrasi ke Google Cloud kami, Anda bisa menemukan informasi teknis lengkap dan saran yang Anda butuhkan untuk membantu merencanakan dan menjalankan migrasi yang berhasil. Untuk membantu Anda memulai lebih cepat, entri blog ini memberikan garis besar tingkat tinggi dan link ke bagian dokumentasi yang relevan sehingga Anda bisa memperoleh lebih banyak informasi.
Sebelum memulai migrasi, Anda harus memiliki beberapa pemahaman mendasar tentang Google Cloud, lingkungan Anda, dan pendekatan migrasi yang berbeda:
1. Pahami perbedaan antara Google Cloud dan lingkungan saat ini. Lingkungan sumber bisa berupa lingkungan lokal atau lingkungan hosting pribadi. Lingkungan ini memiliki model operasional yang berbeda dibandingkan dengan cloud publik, dari sudut pandang keamanan fisik, jaringan, daya, hardware, dan virtualisasi.
2. Identifikasi tipe beban kerja yang perlu dimigrasikan. Kami menyarankan Anda memulai migrasi dengan mengklasifikasikan beban kerja sebagai beban kerja lama, atau cloud-native. Beban kerja lama dikembangkan tanpa mempertimbangkan lingkungan cloud, dengan dukungan terbatas untuk sumber daya penskalaan seperti disk dan komputasi. Akibatnya, beban kerja ini sulit dimodifikasi dan berat untuk dijalankan serta dirawat. Bila didesain mengikuti praktik terbaik, beban kerja cloud-native secara native skalabel, portabel, tersedia, dan aman. Akibatnya, beban kerja cloud-native cenderung meningkatkan produktivitas dan keluwesan developer, karena developer bisa berfokus pada beban kerja aktual, daripada menghabiskan upaya untuk mengelola lingkungan pengembangan dan runtime.
3. Tentukan tingkat kematangan organisasi Anda untuk teknologi cloud. Ketika diidentifikasi sejak awal, kesenjangan keterampilan bisa diatasi sebagai bagian dari proses migrasi melalui tindakan seperti belajar mandiri, pelatihan, atau bimbingan sejawat. Anda bisa menggunakan Cloud Adoption Framework dari Google Cloud untuk mengukur kematangan adopsi cloud organisasi Anda.
4. Pahami berbagai tipe pendekatan migrasi dan konsekuensinya, karena beban kerja yang berbeda mungkin memerlukan pendekatan migrasi yang berbeda. Kami mendefinisikan tiga tipe migrasi:
Lift and shift. Anda memigrasikan beban kerja, dengan menerapkan perubahan paling sedikit.
Improve and move. Anda memodifikasi bagian beban kerja untuk mengadopsi pendekatan cloud-native sebagai bagian dari migrasi.
Rip and replace. Anda mencabut beban kerja, lalu menulis beban kerja baru, dengan mengadopsi pendekatan cloud-native.
Untuk informasi selengkapnya tentang tipe migrasi, lihat bagian panduan migrasi di Tipe migrasi.
Secara garis besar, perjalanan migrasi bisa ditangkap sebagai proses empat fase: Assess, Plan, Deploy, dan Optimize. Memang lebih mudah menunjukkannya secara linier, tetapi hal ini tidaklah sesederhana itu, karena fase ini sering kali terjadi secara paralel untuk beban kerja yang berbeda.
Fase ini dibangun berdasarkan semua pekerjaan awal yang telah dilakukan, dengan fokus pada inventarisasi beban kerja yang direncanakan untuk dimigrasikan dan masing-masing dependensinya. Hal-hal yang perlu dipikirkan meliputi (tetapi tidak terbatas pada) persyaratan hardware dan kinerja, pengguna, perizinan, kepatuhan, dan dependensi beban kerja. Kemudian, petakan informasi ini ke dalam katalog aplikasi yang merangkum informasi beberapa pertanyaan utama, misalnya:
Apakah beban kerja memiliki dependensi, atau merupakan dependensi untuk beban kerja lain
Seberapa penting beban kerja ini bagi bisnis
Bagaimana tingkat kesulitan saat melakukan migrasi beban kerja
Katalog aplikasi akan memberi Anda tampilan tingkat tinggi besarnya upaya yang diperlukan untuk memigrasikan semua beban kerja yang berbeda. Anda juga bisa menggunakan fitur otomatis seperti StratoZone yang dapat memindai beban kerja yang ada dan memberi Anda informasi berdasarkan data yang dikumpulkan. StratoZone tidak hanya membantu penemuan tetapi juga bisa membantu Anda memetakan instance untuk mencocokkan instance Google Compute Engine. Lihat entri blog ini untuk pengantar StratoZone. Informasi tambahan tentang cara melakukan penemuan juga tersedia di bagian Mengategorikan aplikasi Anda.
Untuk lebih memahami besarnya risiko atau upaya, Anda harus melakukan bukti konsep (POC) yang menguji berbagai kasus penggunaan dan persyaratan beban kerja, dengan fokus pada beban kerja yang lebih rumit. Ini membantu mendapatkan lebih banyak informasi lebih awal serta mengurangi hal-hal yang tidak diketahui.
Anda juga harus melakukan penghitungan total biaya kepemilikan (TCO) pada fase ini, sehingga memberikan visibilitas bisnis mengenai seperti apa pengeluaran cloud mereka setelah migrasi, dibandingkan dengan lingkungan saat ini. Saat berpindah dari lingkungan lokal ke cloud, sering kali ada biaya tersembunyi yang terlewat saat menghitung biaya di pusat data lama. Kami mencantumkan beberapa hal yang harus diperhatikan saat membangun TCO ini di bagian Menghitung total biaya kepemilikan di panduan kami. Membuat bisnis memahami pergeseran model biaya dan semua keuntungan tambahan yang diperoleh akan sangat penting untuk keberhasilan migrasi.
Terakhir, Anda perlu memutuskan beban kerja yang akan dimigrasikan terlebih dahulu. Jawabannya tentu bervariasi dari masing-masing bisnis yang bergantung pada banyak faktor berbeda, seperti nilai bisnis beban kerja, kompleksitas migrasi, dan ketersediaan serta persyaratan beban kerja. Untuk membantu memutuskan hal ini, ada baiknya mengadakan pertemuan dengan para pakar di bidangnya tentang beban kerja yang berbeda dan membahas daftar faktor yang disepakati bersama. Keberhasilan dengan beban kerja pertama adalah kunci keberhasilan keseluruhan perjalanan migrasi Anda, karena kesuksesan awal akan memberikan kepercayaan dan keyakinan, sedangkan kesulitan di awal terkadang bisa menggagalkan keseluruhan project migrasi.
Fase berikutnya adalah merencanakan bagian mendasar dari lingkungan cloud baru, yang terdiri dari tetapi tidak terbatas pada:
1. Menetapkan identitas pengguna dan layanan. Bagaimana akun layanan dan pengguna dibuat dan dikelola? Anda bisa memilih antara domain G Suite atau Cloud Identity, dan secara opsional mengintegrasikannya dengan Penyedia Identitas (IdP) yang ada. Baca tentang hal ini di bagian Manajemen Identitas dan Akses.
2. Mendesain hierarki organisasi sumber daya. Bagaimana struktur berbagai sumber daya Google Cloud dibuat secara hierarkis? Node organisasi, folder, dan project menyediakan blok bangunan untuk menyiapkan hierarki organisasi sumber daya. Organisasi sumber daya yang didesain dengan baik menyederhanakan kontrol akses dan manajemen tagihan. Contoh berbagai tipe desain adalah:
Hierarki berorientasi lingkungan - Desain ini memisahkan lingkungan produksi, penjaminan kualitas, dan pengembangan.
Hierarki berorientasi fungsi - Desain ini memecah berbagai fungsi bisnis ke dalam folder mereka sendiri di tingkat atas, dan menerapkan hierarki berorientasi lingkungan di bawahnya.
Hierarki berorientasi granular - Desain ini dibangun di atas hierarki berorientasi fungsi dengan menambahkan organisasi unit bisnis di tingkat atas.
Anda bisa mendalami topik ini di bagian hierarki sumber daya.
3. Menetapkan grup dan peran untuk akses sumber daya. Apa saja peran pengguna yang akan mengakses lingkungan cloud Anda? Izin apa yang harus dimiliki oleh peran yang berbeda ini? Anda perlu membuat peran manajer seperti admin organisasi, admin jaringan, dan admin keamanan untuk mengelola sumber daya cloud. Ini juga merupakan praktik terbaik membuat peran khusus untuk berbagai kelas pengguna yang akan menggunakan lingkungan cloud, misalnya developer, penguji, dan engineer keandalan situs (SRE). Semua memiliki sekumpulan izin minimum yang terkait dengan peran untuk menjalankan tugasnya. Dokumen Praktik terbaik untuk organisasi enterprise memberikan detail selengkapnya tentang topik ini.
4. Mendesain topologi dan konektivitas jaringan Anda. Di region mana Anda akan menerapkan aplikasi? Apakah akan ada konektivitas kembali ke lingkungan sumber? Berapa banyak jaringan terpisah yang perlu Anda siapkan? Jawaban atas pertanyaan ini akan dimasukkan ke dalam cara Anda mendesain Virtual Private Cloud (VPC), yang merupakan jaringan pribadi Anda dalam Google Cloud. Satu VPC memetakan satu jaringan mandiri dalam lingkungan cloud Anda. VPC memiliki subnet, aturan firewall, dan rute yang memungkinkan Anda meniru karakteristik jaringan fisik. Anda juga harus menerapkan praktik terbaik keamanan; Anda bisa membaca tentang semua ini di bagian Keamanan, serta di bagian Mengamankan aplikasi dan data Anda dari panduan Praktik terbaik untuk organisasi enterprise. Konektivitas kembali ke lingkungan sumber juga bisa dilakukan menggunakan opsi seperti interkoneksi langsung, peering, atau VPN. Untuk informasi selengkapnya, baca bagian Konektivitas dan jaringan.
Setelah fondasi migrasi siap, langkah berikutnya adalah menentukan pendekatan terbaik untuk menerapkan beban kerja ke lingkungan cloud Anda. Anda tidak perlu melakukan pendekatan yang sama untuk semua beban kerja, tetapi, semakin terstandardisasi prosesnya, semakin besar peluang untuk pembelajaran lintas tim dan penyempurnaan proses penerapan. Contoh dari pendekatan penerapan yang berbeda adalah:
1. Penerapan manual penuh. Pendekatan ini adalah cara termudah dan tercepat untuk mengaktifkan dan menjalankan beban kerja Anda, dan bisa dilakukan langsung dari Cloud Console atau Cloud SDK. Meskipun penerapan manual mungkin boleh saja untuk eksperimen, kami tidak merekomendasikan pendekatan ini untuk penerapan beban kerja produksi karena rentan error, tidak dapat diulang, dan cenderung didokumentasikan dengan buruk. Jika Anda saat ini menggunakan penerapan manual, bagian Migrasi dari penerapan manual ke penerapan otomatis dalam container akan dapat membantu Anda memperbaiki proses.
Untuk lingkungan produksi, pilihan yang lebih baik adalah menggunakan layanan yang bisa secara otomatis mereplikasikan beban kerja yang ada di lingkungan Anda saat ini dan menerapkannya ke GCP. Google Cloud menawarkan beberapa layanan seperti itu:
Migrate for Compute Engine - Layanan ini memungkinkan Anda melakukan migrasi aplikasi berbasis VM dari lingkungan yang ada (mis. VMware, Azure, AWS) ke GCP dengan periode nonaktif dan risiko minimal.
Migrate for Anthos - Daripada melakukan migrasi VM sebagaimana adanya, Anda bisa dengan cerdas mengonversi dan menjalankan beban kerja di VM dan memigrasikan beban kerja tersebut ke dalam container di GKE. Hal ini sering kali mengurangi biaya dan manajemen.
Database Migration Solutions - Baik melalui pihak ketiga seperti Striim, atau menggunakan dukungan replikasi native di Google Cloud SQL, ada banyak teknik berbeda untuk memasukkan data Anda ke Google Cloud.
VMware Engine - Migrasikan semua beban kerja berbasis VMware yang ada dari infrastruktur lokal Anda tanpa perubahan apa pun langsung ke Google Cloud VMware Engine. Ini memungkinkan Anda menggunakan kembali semua fitur penerapan VMware yang sudah ada dan segera memulai migrasi, dan dengan mudah menambahkan beban kerja baru dengan framework VMware dalam Google Cloud.
2. Penerapan menggunakan fitur manajemen konfigurasi. Penggunaan fitur manajemen konfigurasi (CM) seperti Ansible, Chef, atau Puppet menyediakan cara yang dapat diulang, otomatis dan terkontrol untuk menjalankan penerapan Anda. Namun, fitur ini paling cocok untuk penyediaan dan konfigurasi, dan kurang cocok untuk penerapan beban kerja. Hal ini karena fitur tersebut memerlukan logika penerapan khusus untuk menangani prosedur seperti penerapan bebas periode nonaktif, penerapan blue-green, atau peluncuran update, dan akhirnya menjadi semakin sulit dikelola dan dipertahankan dalam jangka panjang.
3. Penerapan dengan menggunakan fitur orkestrasi container. Jika beban kerja Anda dalam container, Anda bisa menggunakan Google Kubernetes Engine (GKE) untuk menangani proses penerapan. Orkestrator Kubernetes langsung mendukung banyak tipe logika penerapan seperti penerapan bebas periode nonaktif dan peluncuran update yang kreatif. Selain itu, jika beban kerja Anda masih pada VM yang menjalankan GCE, Azure, atau AWS Migrate for Anthos memungkinkan Anda mengonversi VM menjadi container secara otomatis. Anda bisa mendapatkan keuntungan menjalankan di container dengan lebih cepat.
4. Penerapan secara otomatis. Proses penerapan otomatis dipicu berdasarkan beberapa tindakan yang menghasilkan perubahan dalam beban kerja dan bisa dibuat di atas fitur orkestrasi apa pun yang mendukung skrip. Penerapan otomatis memungkinkan Anda mengefisienkan dan menstandardisasi proses penerapan Anda yang akan mengurangi error manusia.
Anda bisa menggunakan fitur seperti Jenkins, SonarQube, Cloud Build, atau Spinnaker untuk membangun pipeline penerapan otomatis end-to-end di samping fitur orkestrasi yang ada. Langkah-langkah kunci proses penerapan otomatis adalah:
Peninjauan kode. Setiap perubahan pada basis kode Anda harus ditinjau oleh sejawat untuk memastikan kualitas perubahan sebelum menggabungkannya dalam basis kode.
Continuous integration (CI). Setelah digabungkan, fitur CI menjalankan semua pengujian terhadap versi baru basis kode dan memastikan bahwa tidak ada pengujian yang gagal. Setelah berhasil, CI akan menandai build tersebut.
Produksi artefak. Setiap build yang berhasil akan menghasilkan artefak. Container adalah salah satu contoh artefak. Pengujian juga bisa dijalankan dengan menggunakan fitur seperti Serverspec untuk memastikan artefak berfungsi dengan baik.
Continuous deployment (CD).Artefak yang berhasil kemudian diterapkan ke dalam lingkungan cloud pengembangan atau penjaminan kualitas, setelah itu dilakukan serangkaian uji fungsional lain terhadap penerapan tersebut untuk memastikannya berjalan dengan baik. Setelah pengujian berhasil, penerapan kemudian bisa diterapkan ke lingkungan produksi Anda, baik secara otomatis, atau setelah dipicu secara manual oleh operator.
5. Penerapan dengan menerapkan pola infrastruktur sebagai kode. Ide di balik infrastruktur sebagai kode adalah untuk menangani konfigurasi dan penyediaan sumber daya cloud dengan cara yang sama seperti memperlakukan kode sumber untuk beban kerja Anda. Mirip dengan cara menerapkan versi baru beban kerja melalui serangkaian langkah dan pengujian otomatis, setiap perubahan pada konfigurasi infrastruktur juga melalui serangkaian langkah yang melibatkan pengujian sebelum diterapkan ke lingkungan cloud target. Ini adalah praktik terbaik yang kami rekomendasikan karena memberikan pengulangan dan keterlacakan, yang meningkatkan kecepatan penerapan secara keseluruhan. Proses ini bisa diimplementasikan dengan menggunakan fitur seperti Terraform dan layanan terkelola seperti Deployment Manager.
Setelah penerapan dasar beban kerja Anda berjalan dan diuji di lingkungan Google Cloud yang baru, Anda bisa mulai meningkatkan fondasi ini. Ini termasuk bagian penting yang harus diselesaikan sebelum memotong traffic saat ini, misalnya melatih tim Anda tentang pedoman operasional cloud baru serta memastikan bahwa logging, pemantauan, dan pemberitahuan untuk beban kerja ini sudah siap.
Aspek lain yang bisa Anda optimalkan setelah beban kerja melayani traffic produksi meliputi:
Pengoptimalan biaya dengan autoscaling
Berpindah ke beban kerja terkelola untuk mengurangi biaya operasional
Mengotomatiskan proses penerapan
Baca tentang cara terbaik melakukan pendekatan ini di bagian Mengoptimalkan lingkungan Anda.
Migrasi besar bisa menjadi hal yang menakutkan bagi tim yang sangat ambisius. Namun dengan metodologi, perencanaan, dan pengujian yang tepat sebelum penerapan, Anda bisa memecah masalah menjadi langkah-langkah yang lebih kecil dan lebih mudah dikelola. Panduan solusi Migrasi ke Google Cloud membahas hal-hal di atas secara lebih detail, juga menyediakan sumber daya tambahan, seperti bagian ‘Mencari Bantuan’, yang bisa Anda gunakan untuk memulai migrasi beban kerja ke cloud.
Jika Anda memerlukan bantuan lebih lanjut dari para profesional yang memiliki rekam jejak migrasi yang berhasil, Organisasi Layanan Profesional Google Cloud menawarkan layanan konsultasi secara langsung atau melalui sejumlah mitra dengan berbagai spesialisasi. Cukup hubungi dan kami bisa membantu Anda!
