Saya telah menjadi penggemar berat Azure DevOps sejak awal, ketika masih disebut Visual Studio Online. Saya menggunakannya untuk tujuan profesional dan pribadi,
dan merekomendasikannya kepada klien konsultasi saya.
Namun, tidak peduli seberapa banyak saya memuji platform ini, seringkali sulit untuk meyakinkan pengembang Node atau Java bahwa Azure DevOps akan baik-baik saja dengan proyek mereka, tidak lebih buruk daripada untuk .NET. Terlepas dari jumlah demonstrasi dan presentasi yang menyangkal prasangka, dalam kelompok mana pun ada orang yang sangat percaya bahwa ADO tidak cocok untuk mereka, karena itu adalah "alat dari Microsoft."
Mengesampingkan perdebatan filosofis, saya dapat menjelaskan sebagian besar perlawanan dengan kurangnya pemahaman tentang bagaimana Azure DevOps berevolusi dari pendahulunya Team Foundation Services (TFS), dan telah menjadi kotak alat terbaik di kelasnya yang mampu mendukung proyek dalam berbagai ukuran "dalam bahasa apa pun dan apa pun platform. " Pertanyaannya adalah, bagaimana saya bisa membuktikan hal ini sekali dan untuk semua?
Saya bermain-main dengan ide ini sedikit, dan kemudian saya sadar. Buktinya perlu dilakukan tanpa membuat demo CI / CD lain untuk layanan microsoft SpringBoot yang digunakan untuk Kubernet pada AWS - itu harus dilakukan dengan pendekatan yang lebih eksentrik.
Dan sekarang sesuatu yang sangat berbeda
Bagaimana jika kita berhenti fokus pada bahasa dan platform modern dan bergerak maju 30 tahun yang lalu untuk melihat apakah alat dan ADO modern dapat digunakan untuk mengembangkan, membangun, memecah menjadi modul dan mengimplementasikan program yang ditulis untuk platform komputer 8-bit?
Seperti dalam kasus demo lain untuk ADO yang saya buat di masa lalu, saya ingin menunjukkan produk yang benar-benar selesai - mulai dari mengedit kode, memeriksanya, dan seterusnya, hingga lingkungan hidup tempat Anda dapat menyaksikan perubahannya.
Secara teori, semua ini terdengar bagus, tetapi pertanyaan sebenarnya adalah - di mana untuk memulai? Ini jelas bukan situasi di mana Anda dapat menjalankan StackOverflow untuk mencari contoh sebelumnya. Namun, setelah mendiskusikan ide itu dengan teman dan kolega (mereka semua memutuskan bahwa saya telah pindah), saya mulai menyusun ide saya.
Saya memutuskan bahwa program demo harus ditulis dalam kode mesin 8-bit untuk Commodore 64 menggunakan editor VS Code. Sumber akan diproses oleh repositori Git pada ADO, dan pipa CI / CD akan bertanggung jawab untuk pembangunan, modul, dan implementasi di Azure. Saya sudah mulai curiga bahwa teman-teman saya benar, dan atap saya sudah hilang, tetapi gagasan ini sepertinya merupakan tantangan yang menarik.
Pilihan Editor
Semua orang tahu pepatah tentang memilih alat yang tepat untuk pekerjaan tertentu. Ini berlaku untuk pekerjaan rumah tangga, perbaikan mobil, dan penulisan kode.
Sebagai pengembang .NET, saya menghabiskan sebagian besar waktu saya di Visual Studio 2017. Jika saya perlu beralih ke proyek Java atau menulis program Android asli, saya meluncurkan IntelliJ atau Android Studio masing-masing. Editor mana yang harus saya gunakan untuk kode mesin C64?
Apakah Anda ingin - percaya atau tidak - tetapi hari ini ada beberapa editor bagus yang cocok untuk menulis CBM. Saya bermain-main dengan beberapa dari mereka, tetapi sebenarnya saya ingin menggunakan Visual Studio Code. Saya menggunakan VS Code untuk proyek-proyek saya yang lain, dan bagi saya kelihatannya sangat fleksibel, nyaman, dan kehadiran integrasi built-in dengan git adalah tambahan yang bagus.
Kelemahan dari solusi ini adalah bahwa saya harus mengorbankan highlight sintaks di assembler 6510, dan saya hanya akan menatap teks hitam pada latar belakang putih. Situasi ini tidak sesuai dengan pernyataan saya tentang "alat yang tepat".
Tiba-tiba, saya memutuskan untuk pergi ke Visual Studio Marketplace, dan melihat apakah sudah ada ekstensi untuk VS Code yang cocok untuk menyelesaikan masalah saya. Saya terkejut menemukan ada beberapa ekstensi yang dirancang untuk berfungsi di assembler. Sayangnya, tidak satu pun dari mereka yang dipenjara karena ACME Cross Assembler yang saya pilih untuk proyek ini.
Ini tidak menghentikan saya, dan, tidak ingin menghidupkan kembali aspek monokrom dari pengembangan tahun 80-an, saya membenamkan diri dalam dokumentasi tentang cara membuat ekstensi untuk VS Code. Beberapa hari kemudian, saya dengan senang hati merilis versi pertama ekstensi untuk Visual Studio Marketplace.
Dan latihan ini ternyata lebih bermanfaat daripada yang tampak pada awalnya.
Pada suatu waktu, saya tidak fokus pada program menulis di assembler. Beberapa kali saya mencoba mempelajarinya, tetapi saya biasanya merasa bosan atau jengkel, dan pindah ke sesuatu yang lain. Setelah membuat plugin, saya tidak hanya belajar tentang mekanisme membuat ekstensi untuk VS Code, tetapi juga memperoleh pemahaman yang baik tentang sintaks yang tidak jelas dan kode operasi.
Berbekal editor yang sesuai dan beberapa buku pemrograman lama dari tahun 80-an, saya mulai menulis kode. Sangat cepat, saya mendapat program kerja yang mengimpor file musik dalam format SID dan memainkan versi 8-bit Beatles When I'm 64 (ini adalah lelucon lama pengguna Commodore, tetapi tampaknya cocok untuk proyek ini tepat).
Sampai sekarang, saya telah menyusun dan menguji program pada laptop. Kode sumber dikomit ke repositori git, jadi langkah selanjutnya adalah kebutuhan untuk membuat build untuk Continuous Integration.
Salah satu kemampuan ADO yang mengesankan adalah kemampuannya untuk menangani hampir semua situasi CI / CD. Di luar kotak, layanan ini menawarkan banyak tugas yang telah ditentukan, memungkinkan Anda untuk dengan cepat membuat rantai CI / CD untuk sebagian besar proyek modern hanya dalam beberapa klik.
Jika kebutuhan Anda bukan bagian dari layanan dasar, maka Marketplace biasanya akan memberi Anda banyak alat yang cocok berbeda. Jika ini tidak berhasil, Anda dapat membuat sketsa skrip PowerShell yang berfungsi sesuai kebutuhan Anda.
Masalah nyata dari proyek ini adalah bahwa meskipun terdapat berbagai fitur layanan, cross-assembler dan disk imaging untuk Commodore 64 tidak ada. Tentu saja, saya bisa membuat mesin virtual khusus di Azure dengan alat yang saya butuhkan, atau mengikuti jalur PowerShell, tetapi apakah itu menarik?
Saya juga tidak suka mesin virtual di cloud, dan untuk latihan ini saya ingin menggunakan Agen Hosted, jadi saya hanya punya satu pilihan. Untuk membuktikan apa tujuan seluruh latihan, saya memutuskan bahwa yang terbaik adalah membuat ekstensi sendiri untuk menangani semua tugas ini.
ACME Cross-Assembler Extension
Ekstensi pertama yang diperlukan untuk rantai CI saya adalah mengkompilasi kode assembler saya ke dalam kode mesin C64. Untuk melakukan ini, saya perlu menginstal cross-assembler di salah satu agen build yang di-host.
Assembler adalah program yang mengubah bahasa assembler yang dapat dibaca manusia menjadi kode mesin nyata yang dirancang untuk penangan biner tertentu. Biasanya, kode mesin dihasilkan untuk prosesor yang digunakan dalam mesin yang menjalankannya. Cross assembler mengambil langkah selanjutnya dalam konversi kode, memungkinkan Anda untuk menghasilkan kode mesin untuk prosesor lain.
Seperti yang saya sebutkan, untuk proyek saya, saya memilih ACME Cross-Assembler, karena direkomendasikan untuk pengembangan untuk Commodore. Ini juga mendukung berbagai proyek 8-bit lainnya, seperti Nintendo Entertainment System atau keluarga Atari menggunakan prosesor 65xx.
Saya menghabiskan sebagian besar hari itu, berdasarkan pada dokumentasi dan contoh-contoh yang disediakan oleh Microsoft dan sumber-sumber lain, untuk menulis, memverifikasi, dan menerbitkan di Marketplace versi ekstensi yang berfungsi.
Saat diluncurkan, tugas secara otomatis mengunduh versi terbaru ACME Cross-Assembler dan meluncurkannya dengan opsi yang memungkinkan Anda membuat file final untuk platform target. Salah satu keuntungan yang terkait dengan pemilihan ACME adalah bahwa sebagian besar parameter untuk membangun program dibangun ke dalam kode sumber, yang meminimalkan jumlah input yang perlu didefinisikan dalam ekstensi.
Adakah yang punya disket pinjaman?
Langkah selanjutnya dalam rantai adalah untuk mentransfer program ke format media yang kompatibel dengan Commodore 64, yaitu, meletakkannya di floppy disk. Pengembang juga tidak menghadapi masalah seperti itu dalam kehidupan sehari-hari. Untungnya, ada aplikasi terpisah untuk tugas ini.
VICE adalah emulator paling populer untuk Commodore. Ini tidak hanya memiliki banyak emulator untuk masing-masing dari berbagai model Commodore, tetapi juga beberapa alat yang berguna, termasuk manajer disk virtual c1541. Gambar disk yang dibuat dengannya dapat digunakan dengan emulator, disalin ke media fisik (5 "disket kerapatan rendah), atau diunduh ke microSD dan digunakan dengan emulator drive SD2IEC.
Berbeda dengan tugas ACME, yang mengambil semua pengaturan dari header file sumber, utilitas disk c1541 bergantung pada CLI, dan pengguna memiliki banyak opsi untuk mengelola disk. Untuk ekstensi saya, saya memutuskan untuk fokus hanya pada properti yang diperlukan untuk tugas saya, tetapi bahkan kemudian saya menghadapi pilihan yang berkaitan dengan seberapa menyeluruh saya perlu membuatnya.
Commodore merilis tiga model drive yang berbeda, berbeda dalam cara mereka menangani volume disk berdasarkan format dan tipe media. Model dasar, yang akrab bagi sebagian besar pengguna, hanya dapat bekerja dengan drive satu sisi dengan kapasitas 170 KB (ya, kilobyte. Tanya orang tua Anda). Model kemudian, 1571, digunakan pada Commodore 128, dapat bekerja dengan drive dua sisi, volume yang meningkat menjadi 340 Kb. Saya memutuskan untuk menambahkan fleksibilitas pada ekstensi, jadi saya menambahkan dukungan untuk berbagai format disk sebagai pengaturan, yang dapat dipilih di antarmuka melalui menu tarik-turun.
Karena saya sudah memiliki contoh yang berfungsi, membuat ekstensi ini berjalan lebih cepat. Saya belajar sesuatu yang baru yang memungkinkan saya untuk memperbaiki kode untuk ekstensi ACME juga.
Seperti dalam kasus cross-assembler, perangkat lunak yang diperlukan diunduh dari repositori proyek open source dan diinstal di agen build. Tugas membuat image disk dalam format yang diinginkan, dan kemudian file dari tugas build disalin ke sana. File yang dihasilkan dipindahkan ke direktori Build Artifacts, tempat Anda dapat mengunduhnya.
Apa yang ternyata - begitu banyak pekerjaan, dan akibatnya Anda perlu mengunduh file? Ini harus menjadi materi pelatihan CI / CD. Jika kita perlu membuktikan posisi kita, kita perlu menggunakan program pada mesin sehingga dapat digunakan sebagai demonstrasi.
Floppinet dinonaktifkan
Menjalankan versi komputer Commodore 64 nyata dan drive 1541 adalah hal yang langka, belum lagi menjadi besar dan berat. Selain itu, mereka tidak dapat menampilkan gambar pada monitor modern tanpa adaptor khusus, dan ini sangat membatasi efektivitas demonstrasi.
Commodore SX-64 (komputer warna "portabel" pertama yang diproduksi dalam jumlah besar) memiliki monitor bawaan, tapi ukurannya setara dengan tas bawaan saya dan beratnya sekitar 10 kg. Bayangkan betapa sulitnya melewati layanan keamanan bandara dengan monster sebesar itu?
C64 Mini yang baru dirilis ini cukup kecil untuk bepergian, kemampuan untuk mengunduh program dari USB dan output HDMI. Dalam beberapa kasus, ini akan menjadi salah satu opsi. Namun dia masih belum mencapai tujuan yang diinginkan.
Masalah sebenarnya bukanlah portabilitas dari besi, tetapi kurangnya otomatisasi. Kebutuhan untuk mentransfer program dari laptop ke mobil menggunakan flash drive tidak sepenuhnya mengungkapkan kemampuan ADO dalam presentasi.
Opsi tanpa server
Seperti yang saya sebutkan, VICE adalah emulator paling populer untuk Commodore. Itu porting ke Windows, Linux, Mac OS X, MS-DOS, dan banyak OS lainnya. Namun, untuk pengembangan cloud, opsi ini membutuhkan konfigurasi VM sebagai host, dan saya ingin bertahan dengan solusi yang tidak memerlukan server.
Selain versi yang disebutkan, VICE memiliki opsi untuk JavaScript yang berfungsi dengan baik di sebagian besar browser. Meskipun pengembangan front-end bukan elemen saya, saya bisa buntung halaman responsif yang layak.
Untuk mengatur rantai rilis, saya mengunggah file dengan gambar disk ke direktori di repositori yang sama. Saya mengaitkan ini dengan memanggil Aplikasi Fungsi Azure, yang mengembalikan daftar gambar disk yang tersedia. Memilih salah satunya dari menu tarik-turun secara otomatis akan memuat dan meluncurkannya dalam emulator JavaScript.
Sistem bekerja tidak hanya dengan program saya, saya berhasil membuat rantai untuk menggunakan dan menjalankan program di Commodore 64 BASIC.
10 PRINT "HELLO WORLD"
20 GOTO 10Kita selesai
DevOps untuk Commodore 64? Itu tidak terpikirkan!
Arti dari latihan ini bukan hanya bukti bahwa ketika mereka mengatakan tentang Azure DevOps yang mendukung "bahasa apa pun dan platform apa pun", mereka tidak hanya berarti segala sesuatu yang berkaitan dengan Microsoft (meskipun versi BASIC untuk Commodore dibeli dengan lisensi dari Microsoft). Ini mengalihkan kita dari berkonsentrasi pada aspek teknologi dan membuat orang melampaui kerangka buatan yang telah mereka tunjuk untuk diri mereka sendiri.
Terlepas dari alasannya, pernyataan seperti "ini tidak akan berhasil di sini" seringkali sama dengan pernyataan "kami selalu melakukannya dengan cara ini, mengapa mengubah sesuatu". Kedua frasa tersebut menunjukkan keengganan untuk tumbuh dan berkembang, beradaptasi dengan lanskap teknologi yang terus berubah, dan mengatasi tantangan yang ditimbulkan oleh perubahan cepat dan agresif ini.
DevOps bukan alat. Alat pada akhirnya hanyalah alat untuk mencapai tujuan, terlepas dari siapa yang menerbitkannya.
Agar DevOps menjadi sukses bagi organisasi, perlu untuk mengubah cara berpikir dan mengembangkan budaya perusahaan kami. Kita perlu menerima banyak ide baru, memikirkan kembali apa yang kita pikir kita ketahui, dan menjauh dari pemikiran seperti "ini tidak akan berhasil di sini," karena kita belum mencobanya sebelumnya.
Membuat rantai CI / CD untuk komputer berusia 30 tahun tidak ada nilainya bagi bisnis, kecuali untuk menggambarkan dengan jelas sudut pandang ini.