One place for hosting & domains

      How To Deploy Multiple Environments in Your Terraform Project Without Duplicating Code


      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Terraform offers advanced features that become increasingly useful as your project grows in size and complexity. It’s possible to alleviate the cost of maintaining complex infrastructure definitions for multiple environments by structuring your code to minimize repetitions and introducing tool-assisted workflows for easier testing and deployment.

      Terraform associates a state with a backend, which determines where and how state is stored and retrieved. Every state has only one backend and is tied to an infrastructure configuration. Certain backends, such as local or s3, may contain multiple states. In that case, the pairing of state and infrastructure to the backend is describing a workspace. Workspaces allow you to deploy multiple distinct instances of the same infrastructure configuration without storing them in separate backends.

      In this tutorial, you’ll first deploy multiple infrastructure instances using different workspaces. You’ll then deploy a stateful resource, which, in this tutorial, will be a DigitalOcean Volume. Finally, you’ll reference pre-made modules from the Terraform Registry, which you can use to supplement your own.

      Prerequisites

      • A DigitalOcean Personal Access Token, which you can create via the DigitalOcean Control Panel. You can find instructions for this in the How to Generate a Personal Access Token tutorial.
      • Terraform installed on your local machine and a project set up with the DO provider. Complete Step 1 and Step 2 of the How To Use Terraform with DigitalOcean tutorial, and be sure to name the project folder terraform-advanced, instead of loadbalance. During Step 2, do not include the pvt_key variable and the SSH key resource.

      Note: We have specifically tested this tutorial using Terraform 0.13.

      Deploying Multiple Infrastructure Instances Using Workspaces

      Multiple workspaces are useful when you want to deploy or test a modified version of your main infrastructure without creating a separate project and setting up authentication keys again. Once you have developed and tested a feature using the separate state, you can incorporate the new code into the main workspace and possibly delete the additional state. When you init a Terraform project, regardless of backend, Terraform creates a workspace called default. It is always present and you can never delete it.

      However, multiple workspaces are not a suitable solution for creating multiple environments, such as for staging and production. Therefore workspaces, which only track the state, do not store the code or its modifications.

      Since workspaces do not track the actual code, you should manage the code separation between multiple workspaces at the version control (VCS) level by matching them to their infrastructure variants. How you can achieve this is dependent on the VCS tool itself; for example, in Git branches would be a fitting abstraction. To make it easier to manage the code for multiple environments, you can break them up into reusable modules, so that you avoid repeating similar code for each environment.

      Deploying Resources in Workspaces

      You’ll now create a project that deploys a Droplet, which you’ll apply from multiple workspaces.

      You’ll store the Droplet definition in a file called droplets.tf.

      Assuming you’re in the terraform-advanced directory, create and open it for editing by running:

      Add the following lines:

      droplets.tf

      resource "digitalocean_droplet" "web" {
        image  = "ubuntu-18-04-x64"
        name   = "web-${terraform.workspace}"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      

      This definition will create a Droplet running Ubuntu 18.04 with one CPU core and 1 GB RAM in the fra1 region. Its name will contain the name of the current workspace it is deployed from. When you’re done, save and close the file.

      Apply the project for Terraform to run its actions with:

      • terraform apply -var "do_token=${DO_PAT}"

      Your output will be similar to the following:

      Output

      An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.web will be created + resource "digitalocean_droplet" "web" { + backups = false + created_at = (known after apply) + disk = (known after apply) + id = (known after apply) + image = "ubuntu-18-04-x64" + ipv4_address = (known after apply) + ipv4_address_private = (known after apply) + ipv6 = false + ipv6_address = (known after apply) + ipv6_address_private = (known after apply) + locked = (known after apply) + memory = (known after apply) + monitoring = false + name = "web-default" + price_hourly = (known after apply) + price_monthly = (known after apply) + private_networking = (known after apply) + region = "fra1" + resize_disk = true + size = "s-1vcpu-1gb" + status = (known after apply) + urn = (known after apply) + vcpus = (known after apply) + volume_ids = (known after apply) + vpc_uuid = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy. ...

      Enter yes when prompted to deploy the Droplet in the default workspace.

      The name of the Droplet will be web-default, because the workspace you start with is called default. You can list the workspaces to confirm that it’s the only one available:

      You’ll receive the following output:

      Output

      * default

      The asterisk (*) means that you currently have that workspace selected.

      Create and switch to a new workspace called testing, which you’ll use to deploy a different Droplet, by running workspace new:

      • terraform workspace new testing

      You’ll have output similar to:

      Output

      Created and switched to workspace "testing"! You're now on a new, empty workspace. Workspaces isolate their state, so if you run "terraform plan" Terraform will not see any existing state for this configuration.

      You plan the deployment of the Droplet again by running:

      • terraform plan -var "do_token=${DO_PAT}"

      The output will be similar to the previous run:

      Output

      An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.web will be created + resource "digitalocean_droplet" "web" { + backups = false + created_at = (known after apply) + disk = (known after apply) + id = (known after apply) + image = "ubuntu-18-04-x64" + ipv4_address = (known after apply) + ipv4_address_private = (known after apply) + ipv6 = false + ipv6_address = (known after apply) + ipv6_address_private = (known after apply) + locked = (known after apply) + memory = (known after apply) + monitoring = false + name = "web-testing" + price_hourly = (known after apply) + price_monthly = (known after apply) + private_networking = (known after apply) + region = "fra1" + resize_disk = true + size = "s-1vcpu-1gb" + status = (known after apply) + urn = (known after apply) + vcpus = (known after apply) + volume_ids = (known after apply) + vpc_uuid = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy. ...

      Notice that Terraform plans to deploy a Droplet called web-testing, which it has named differently from web-default. This is because the default and testing workspaces have separate states and have no knowledge of each other’s resources—even though they stem from the same code.

      To confirm that you’re in the testing workspace, output the current one you’re in with workspace show:

      The output will be the name of the current workspace:

      Output

      testing

      To delete a workspace, you first need to destroy all its deployed resources. Then, if it’s active, you need to switch to another one using workspace select. Since the testing workspace here is empty, you can switch to default right away:

      • terraform workspace select default

      You’ll receive output of Terraform confirming the switch:

      Output

      Switched to workspace "default".

      You can then delete it by running workspace delete:

      • terraform workspace delete testing

      Terraform will then perform the deletion:

      Output

      Deleted workspace "testing"!

      You can destroy the Droplet you’ve deployed in the default workspace by running:

      • terraform destroy -var "do_token=${DO_PAT}"

      Enter yes when prompted to finish the process.

      In this section, you’ve worked in multiple Terraform workspaces. In the next section, you’ll deploy a stateful resource.

      Deploying Stateful Resources

      Stateless resources do not store data, so you can create and replace them quickly, because they are not unique. Stateful resources, on the other hand, contain data that is unique or not simply re-creatable; therefore, they require persistent data storage.

      Since you may end up destroying such resources, or multiple resources require their data, it’s best to store it in a separate entity, such as DigitalOcean Volumes.

      Volumes are objects that you can attach to Droplets (servers), but are separate from them, and provide additional storage space. In this step, you’ll define the Volume and connect it to a Droplet in droplets.tf.

      Open it for editing:

      Add the following lines:

      droplets.tf

      resource "digitalocean_droplet" "web" {
        image  = "ubuntu-18-04-x64"
        name   = "web-${terraform.workspace}"
        region = "fra1"
        size   = "s-1vcpu-1gb"
      }
      
      resource "digitalocean_volume" "volume" {
        region                  = "fra1"
        name                    = "new-volume"
        size                    = 10
        initial_filesystem_type = "ext4"
        description             = "New Volume for Droplet"
      }
      
      resource "digitalocean_volume_attachment" "volume_attachment" {
        droplet_id = digitalocean_droplet.web.id
        volume_id  = digitalocean_volume.volume.id
      }
      

      Here you define two new resources, the Volume itself and a Volume attachment. The Volume will be 10GB, formatted as ext4, called new-volume, and located in the same region as the Droplet. To connect the Volume to the Droplet, since they are separate entities, you define a Volume attachment object. volume_attachment takes the Droplet and Volume IDs and instructs the DigitalOcean cloud to make the Volume available to the Droplet as a disk device.

      When you’re done, save and close the file.

      Plan this configuration by running:

      • terraform plan -var "do_token=${DO_PAT}"

      The actions that Terraform will plan will be the following:

      Output

      An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.web will be created + resource "digitalocean_droplet" "web" { + backups = false + created_at = (known after apply) + disk = (known after apply) + id = (known after apply) + image = "ubuntu-18-04-x64" + ipv4_address = (known after apply) + ipv4_address_private = (known after apply) + ipv6 = false + ipv6_address = (known after apply) + ipv6_address_private = (known after apply) + locked = (known after apply) + memory = (known after apply) + monitoring = false + name = "web-default" + price_hourly = (known after apply) + price_monthly = (known after apply) + private_networking = (known after apply) + region = "fra1" + resize_disk = true + size = "s-1vcpu-1gb" + status = (known after apply) + urn = (known after apply) + vcpus = (known after apply) + volume_ids = (known after apply) + vpc_uuid = (known after apply) } # digitalocean_volume.volume will be created + resource "digitalocean_volume" "volume" { + description = "New Volume for Droplet" + droplet_ids = (known after apply) + filesystem_label = (known after apply) + filesystem_type = (known after apply) + id = (known after apply) + initial_filesystem_type = "ext4" + name = "new-volume" + region = "fra1" + size = 10 + urn = (known after apply) } # digitalocean_volume_attachment.volume_attachment will be created + resource "digitalocean_volume_attachment" "volume_attachment" { + droplet_id = (known after apply) + id = (known after apply) + volume_id = (known after apply) } Plan: 3 to add, 0 to change, 0 to destroy. ...

      The output details that Terraform would create a Droplet, a Volume, and a Volume attachment, which connects the Volume to the Droplet.

      You’ve now defined and connected a Volume (a stateful resource) to a Droplet. In the next section, you’ll review public, pre-made Terraform modules that you can incorporate in your project.

      Referencing Pre-made Modules

      Aside from creating your own custom modules for your projects, you can also use pre-made modules and providers from other developers, which are publicly available at Terraform Registry.

      In the modules section you can search the database of available modules and sort by provider in order to find the module with the functionality you need. Once you’ve found one, you can read its description, which lists the inputs and outputs the module provides, as well as its external module and provider dependencies.

      Terraform Registry - SSH key Module

      You’ll now add the DigitalOcean SSH key module to your project. You’ll store the code separate from existing definitions in a file called ssh-key.tf. Create and open it for editing by running:

      Add the following lines:

      ssh-key.tf

      module "ssh-key" {
        source         = "clouddrove/ssh-key/digitalocean"
        key_path       = "~/.ssh/id_rsa.pub"
        key_name       = "new-ssh-key"
        enable_ssh_key = true
      }
      

      This code defines an instance of the clouddrove/droplet/digitalocean module from the registry and sets some of the parameters it offers. It should add a public SSH key to your account by reading it from the ~/.ssh/id_rsa.pub.

      When you’re done, save and close the file.

      Before you plan this code, you must download the referenced module by running:

      You’ll receive output similar to the following:

      Output

      Initializing modules... Downloading clouddrove/ssh-key/digitalocean 0.13.0 for ssh-key... - ssh-key in .terraform/modules/ssh-key Initializing the backend... Initializing provider plugins... - Using previously-installed digitalocean/digitalocean v1.22.2 Terraform has been successfully initialized! ...

      You can now plan the code for the changes:

      • terraform plan -var "do_token=${DO_PAT}"

      You’ll receive output similar to this:

      Output

      Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: ... # module.ssh-key.digitalocean_ssh_key.default[0] will be created + resource "digitalocean_ssh_key" "default" { + fingerprint = (known after apply) + id = (known after apply) + name = "devops" + public_key = "ssh-rsa ... demo@clouddrove" } Plan: 4 to add, 0 to change, 0 to destroy. ...

      The output shows that you would create the SSH key resource, which means that you downloaded and invoked the module from your code.

      Conclusion

      Bigger projects can make use of some advanced features Terraform offers to help reduce complexity and make maintenance easier. Workspaces allow you to test new additions to your code without touching the stable main deployments. You can also couple workspaces with a version control system to track code changes. Using pre-made modules can also shorten development time, but may incur additional expenses or time in the future if the module becomes obsolete.

      For further resources on using Terraform, check out our How To Manage Infrastructure With Terraform series.



      Source link

      Cara Memformat Kode dengan Prettier di Visual Studio Code


      Pengantar

      Memformat kode secara konsisten merupakan tantangan, tetapi alat pengembang modern memungkinkan pengembang mempertahankan konsistensi secara otomatis di seluruh basis kode tim Anda.

      Dalam artikel ini, Anda akan menyiapkan Prettier untuk memformat kode Anda secara otomatis di Visual Studio Code, yang juga dikenal sebagai VS Code.

      Untuk keperluan demonstrasi, inilah kode sampel yang akan Anda format:

      const name = "James";
      
      const person ={first: name
      }
      
      console.log(person);
      
      const sayHelloLinting = (fName) => {
      console.log(`Hello linting, ${fName}`)
      }
      
      sayHelloLinting('James');
      

      Jika sudah biasa memformat kode, Anda mungkin memperhatikan beberapa kesalahan langkah:

      • Campuran tanda kutip tunggal dan ganda.
      • Properti pertama objek person harus berada di barisnya sendiri.
      • Pernyataan konsol di dalam fungsi harus diinden.
      • Anda mungkin atau mungkin tidak suka tanda kurung opsional yang mengurung parameter fungsi panah.

      Prasyarat

      Untuk mengikuti tutorial ini, Anda perlu mengunduh dan menginstal Visual Studio Code.

      Untuk bekerja dengan Prettier di Visual Studio Code, Anda perlu menginstal ekstensi. Caranya, cari Prettier - Code Formatter di panel ekstensi VS Code. Jika Anda menginstalnya untuk pertama kali, Anda akan melihat tombol install sebagai ganti tombol uninstall yang ditunjukkan di sini:

      Readme ekstensi Prettier

      Langkah 1 — Menggunakan Perintah Format Document

      Dengan ekstensi Prettier yang telah terinstal, kini Anda dapat memanfaatkannya untuk memformat kode. Untuk memulai, mari kita mendalami penggunaan perintah Format Document. Perintah ini akan membuat kode Anda lebih konsisten dengan pengaturan jarak yang telah diformat, pelipatan baris, dan tanda kutip.

      Untuk membuka palet perintah, Anda dapat menggunakan COMMAND+ SHIFT + P di macOS atau CTRL + SHIFT + P di Windows.

      Dalam palet perintah, cari format, kemudian pilih Format Document.

      Perintah palet dibuka dengan hasil format

      Nanti, Anda mungkin diminta memilih format yang akan digunakan. Caranya, klik tombol Configure:

      Konfirmasi untuk memilih format asali

      Kemudian, pilih Prettier – Code Formatter.

      Memilih Prettier

      Catatan: Jika Anda tidak melihat konfirmasi untuk memilih format asali, Anda dapat mengubahnya secara manual di Settings. Atur Editor: Default Formatter ke ebsenp.prettier-vscode.

      Kode Anda sekarang telah diformat dengan jarak, pelipatan baris, dan tanda kutip yang konsisten:

      const name="James";
      
      const person = { first: name };
      
      console.log(person);
      
      const sayHelloLinting = (fname) => {
        console.log(`Hello linting, ${fName}`);
      }
      
      sayHelloLinting('James');
      

      Ini juga dapat digunakan di berkas CSS. Anda dapat mengubah kode dengan indentasi, kurung kurawal, baris baru, dan titik-koma yang tidak konsisten menjadi kode yang diformat dengan baik. Misalnya:

      body {color: red;
      }
      h1 {
        color: purple;
      font-size: 24px
      }
      

      Akan diformat menjadi:

      body {
        color: red;
      }
      h1 {
        color: purple;
        font-size: 24px;
      }
      

      Karena kita telah mendalami perintah ini, mari kita lihat cara mengimplementasikannya agar dijalankan secara otomatis.

      Langkah 2 — Memformat Kode saat Disimpan

      Sejauh ini, Anda harus menjalankan perintah secara manual untuk memformat kode. Untuk mengotomatiskan proses ini, Anda dapat memilih pengaturan di VS Code agar berkas Anda diformat secara otomatis saat disimpan. Hal ini juga memastikan bahwa kode tidak akan diperiksa karena kontrol versi yang tidak diformat.

      Untuk mengubah pengaturan ini, tekan COMMAND +, di macOS atau CTRL +, di Windows untuk membuka menu Settings. Setelah menu dibuka, cari Editor: Format On Save dan pastikan opsi itu telah dicentang:

      Editor: Format On Save dicentang

      Setelah ini diatur, Anda dapat menulis kode seperti biasa dan secara otomatis akan diformat saat menyimpan berkas.

      Langkah 3 — Mengubah Pengaturan Konfigurasi Prettier

      Prettier melakukan banyak hal untuk Anda secara asali, tetapi Anda juga dapat menyesuaikan pengaturannya.

      Buka menu Settings. Kemudian, cari Prettier. Ini akan menampilkan semua pengaturan yang dapat Anda ubah:

      Pengaturan Konfigurasi untuk Prettier

      Berikut ini beberapa pengaturan paling umum:

      • Single Quote – Memilih antara tanda kutip tunggal dan ganda.
      • Semi – Memilih jika akan menyertakan atau tidak menyertakan titik-koma di akhir baris.
      • Tab Width – Menentukan jumlah spasi yang Anda inginkan untuk menyisipkan tab.

      Kelemahan menggunakan menu pengaturan bawaan di VS Code adalah tidak menjamin konsistensi di semua pengembang dalam tim Anda.

      Langkah 4 — Membuat Berkas Konfigurasi Prettier

      Jika Anda mengubah pengaturan di VS Code, orang lain mungkin memiliki konfigurasi yang sepenuhnya berbeda di mesin mereka. Anda dapat membuat pemformatan yang konsisten untuk tim dengan membuat berkas konfigurasi bagi proyek Anda.

      Buat berkas baru bernama .prettierrc.extension dengan salah satu ekstensi berikut:

      Berikut ini contoh berkas konfigurasi sederhana yang menggunakan JSON:

      {
        "trailingComma": "es5",
        "tabWidth": 4,
        "semi": false,
        "singleQuote": true
      }
      

      Untuk lebih spesifik mengenai berkas konfigurasi, lihat Dokumentasi Prettier. Setelah membuat dan memeriksanya di proyek, Anda dapat memastikan bahwa setiap anggota tim mengikuti aturan pemformatan yang sama.

      Kesimpulan

      Memiliki kode yang konsisten adalah praktik yang baik. Hal ini sangat bermanfaat saat bekerja di proyek bersama beberapa kolaborator. Menyepakati seperangkat konfigurasi akan membantu dalam kemudahan membaca dan memahami kode. Akan ada lebih banyak waktu yang dapat dicurahkan untuk memecahkan masalah teknis yang menantang, bukannya berkutat dengan masalah yang telah diselesaikan seperti indentasi kode.

      Prettier menjaga konsistensi dalam pemformatan kode Anda dan mengotomatiskan prosesnya.



      Source link

      Cara Menggunakan Integrasi Git di Visual Studio Code


      Pengantar

      Visual Studio Code (VS Code) telah menjadi salah satu editor paling populer untuk pengembangan web. Editor ini memperoleh popularitas demikian banyak berkat fitur bawaannya, termasuk integrasi kontrol sumber, yang dinamai Git. Memanfaatkan kemampuan Git dari dalam VS Code dapat membuat alur kerja Anda lebih efisien dan tangguh.

      Dalam tutorial ini, Anda akan mendalami penggunaan Integrasi Kontrol Sumber di VS Code dengan Git.

      Prasyarat

      Untuk mengikuti tutorial ini, Anda membutuhkan hal berikut ini:

      • Git yang terinstal di mesin Anda. Untuk lebih detail mengenai cara melakukannya, tinjaulah tutorial Memulai dengan Git.
      • Versi terbaru Visual Studio Code yang terinstal di mesin Anda.

      Langkah 1 — Memahami Tab Source Control

      Hal pertama yang perlu dilakukan untuk memanfaatkan integrasi kontrol sumber adalah menginisialisasi proyek sebagai repositori Git.

      Buka Visual Studio Code dan akseslah terminal bawaan. Anda dapat membukanya dengan pintasan keyboard CTRL + ` di Linux, macOS, atau Windows.

      Di terminal, buat direktori untuk proyek baru dan berpindah ke direktori itu:

      • mkdir git_test
      • cd git_test

      Kemudian, buat repositori Git:

      Cara lain untuk melakukannya pada Visual Studio Code adalah dengan membuka tab Source Control (ikon yang terlihat seperti persimpangan jalan) di panel sisi kiri:

      Ikon Source Control

      Selanjutnya, pilih Open Folder:

      Tangkapan layar yang menggambarkan tombol Open Folder

      Ini akan membuka penjelajah berkas Anda ke direktori saat ini. Pilih direktori proyek yang disukai dan klik Open.

      Kemudian, pilih Initialize Repository:

      Tangkapan layar yang menggambarkan tombol Initialize Repository

      Jika Anda memeriksa sistem berkas, Anda akan melihatnya menyertakan direktori .git. Caranya, gunakan terminal untuk menyusuri direktori proyek Anda dan menampilkan daftar semua konten:

      Anda akan melihat direktori .git yang dibuat:

      Output

      Karena repositori telah diinisialisasi, tambahkan berkas bernama index.html.

      Setelah melakukannya, Anda akan melihat berkas baru di panel Source Control ditampilkan dengan huruf U di sebelahnya.** U** singkatan untuk untracked file, artinya berkas yang baru atau telah diubah, tetapi belum ditambahkan ke repositori:

      Tangkapan layar dari berkas tak terlacak dengan indikator huruf U

      Kini Anda dapat mengklik ikon plus (+) melalui daftar berkas index.html untuk melacak berkas menurut repositori.

      Setelah ditambahkan, huruf di sebelah berkas akan berubah menjadi A.A menyatakan berkas baru yang telah ditambahkan ke repositori.

      Untuk menerapkan perubahan, ketikkan pesan penerapan ke kotak masukan di bagian atas panel Source Control. Kemudian, klik ikon centang untuk melakukan penerapan.

      Tangkapan layar dari berkas yang ditambahkan dengan indikator huruf A dan pesan penerapan

      Setelah melakukannya, Anda akan melihat bahwa tidak ada perubahan yang menunggu.

      Selanjutnya, tambahkan sedikit konten ke berkas index.html.

      Anda dapat menggunakan pintasan Emmet untuk menghasilkan kerangka HTML5 di VS Code dengan menekan tombol !, diikuti dengan tombol Tab. Lanjutkan dan tambahkan sesuatu di <body> seperti judul <h1> lalu simpan.

      Di panel kontrol sumber, Anda akan melihat bahwa berkas telah berubah. Huruf M akan ditampilkan di sebelahnya, yang menyatakan bahwa berkas telah dimodifikasi:

      Tangkapan layar dari berkas yang dimodifikasi dengan indikator huruf M

      Untuk latihan, lanjutkan dan terapkan juga perubahan ini.

      Karena kini Anda sudah terbiasa berinteraksi dengan panel kontrol sumber, Anda akan melanjutkan ke menafsirkan indikator gutter.

      Langkah 2 — Menafsirkan Indikator Gutter

      Dalam langkah ini, Anda akan mempelajari sesuatu yang disebut dengan “Gutter” dalam VS Code. Gutter adalah area tipis di sebelah kanan nomor baris.

      Jika Anda telah menggunakan pelipatan kode sebelumnya, ikon maximize dan minimize berada di dalam gutter.

      Mari kita mulai dengan membuat sedikit perubahan pada berkas index.html, misalnya perubahan pada konten dalam tag <h1>. Setelah melakukannya, Anda akan melihat tanda vertikal biru di gutter baris yang Anda ubah. Tanda biru vertikal menunjukkan bahwa baris kode yang bersangkutan telah diubah.

      Sekarang, coba hapus sebuah baris kode. Anda dapat menghapus salah satu baris di bagian <body> dari berkas index.html. Sekarang perhatikan, di gutter ada segitiga merah. Segitiga merah merupakan sebuah baris atau sekelompok baris yang telah dihapus.

      Terakhir, di bawah bagian <body>, tambahkan baris kode baru dan perhatikan bilah hijau. Bilah hijau vertikal menandakan sebuah baris kode yang telah ditambahkan.

      Contoh ini menggambarkan indikator gutter untuk baris yang dimodifikasi, baris yang dihapus, dan baris baru:

      Tangkapan layar dengan contoh tiga tipe indikator gutter

      Langkah 3 — Menjalankan Diff pada Berkas

      VS Code juga memiliki kemampuan untuk menjalankan diff pada berkas. Biasanya, Anda harus mengunduh alat diff terpisah untuk melakukannya, jadi fitur bawaan ini dapat membantu Anda bekerja lebih efisien.

      Untuk melihat diff, buka panel kontrol sumber dan klik ganda berkas yang diubah. Dalam hal ini, klik ganda pada berkas index.html. Anda akan diarahkan ke tampilan umum diff dengan versi berkas saat ini di sebelah kiri dan versi berkas yang diterapkan sebelumnya di sebelah kanan.

      Contoh ini menunjukkan bahwa sebuah baris telah ditambahkan dalam versi saat ini:

      Tangkapan layar dengan contoh tampilan layar belah dari diff

      Langkah 4 — Menggunakan Percabangan

      Dengan berpindah ke bilah bawah, Anda dapat membuat dan berpindah cabang. Jika Anda perhatikan bagian kiri bawah editor, Anda akan melihat ikon kontrol sumber (yang terlihat seperti persimpangan jalan) yang biasanya diikuti dengan master atau nama cabang saat ini.

      Indikator cabang di bilah bawah VS Code yang menampilkan: master

      Untuk membuat cabang, klik nama cabang itu. Menu yang akan muncul memberi Anda kemampuan membuat cabang baru:

      Konfirmasi untuk membuat cabang baru

      Lanjutkan dan buat cabang baru bernama test.

      Sekarang, buat perubahan pada berkas index.html yang menandakan Anda berada di cabang test yang baru, misalnya menambahkan tulisan this is the new test branch.

      Terapkan perubahan itu pada cabang test. Kemudian, klik lagi nama cabang di bagian kiri bawah untuk berpindah kembali ke cabang master.

      Setelah berpindah kembali ke cabang master, Anda akan melihat bahwa tulisan this is the new test branch yang diterapkan pada cabang test tidak ada lagi.

      Langkah 5 — Menggunakan Repositori Jauh

      Tutorial ini tidak akan membahasnya secara mendalam, tetapi melalui panel Source Control, Anda memiliki akses untuk menggunakan repositori jauh. Jika sebelumnya Anda pernah menggunakan repositori jauh, Anda akan melihat perintah yang familier seperti pull, sync, publish, stash, dll.

      Langkah 6 — Menginstal Ekstensi Berguna

      VS Code tidak hanya dilengkapi dengan banyak fungsionalitas bawaan untuk Git, juga ada beberapa ekstensi yang sangat populer untuk menambahkan fungsionalitas tambahan.

      Git Blame

      Ekstensi ini menyediakan kemampuan untuk melihat informasi Git Blame di bilah status baris yang dipilih saat ini.

      Mungkin terdengar merepotkan, tetapi jangan khawatir, ekstensi Git Blame hanyalah masalah kepraktisan, bukan menyulitkan. Pemikiran “menyalahkan” (blame) orang lain karena perubahan kode jauh dari niat mempermalukannya, melainkan agar mengetahui kepada siapa sebaiknya menanyakan potongan kode tertentu.

      Seperti yang Anda lihat di tangkapan layar, ekstensi ini menyediakan pesan singkat menyangkut baris kode saat ini yang sedang Anda kerjakan di bilah alat bawah yang menjelaskan siapa yang melakukan perubahan dan kapan diubah.

      Git Blame di bilah alat bawah

      Git History

      Meskipun Anda dapat melihat perubahan saat ini, menjalankan diff, dan mengelola cabang dengan fitur bawaan di VS Code, alat ini tidak memberikan gambaran mendalam mengenai riwayat Git Anda. Ekstensi Git History mengatasi masalah itu.

      Seperti yang dapat Anda lihat pada gambar di bawah, ekstensi ini memungkinkan Anda untuk mendalami secara menyeluruh tentang riwayat berkas, penulisnya, cabang, dll. Untuk mengaktifkan jendela Git History di bawah, klik kanan pada berkas dan pilih Git: View File History:

      Hasil ekstensi Git History

      Selain itu, Anda dapat membandingkan cabang dan penerapan, membuat cabang dari penerapan itu, dan banyak lagi.

      Git Lens

      Git Lens banyak menambah kemampuan Git yang disertakan dalam Visual Studio Code. Ini membantu Anda untuk memvisualisasikan secara cepat penulisan kode melalui anotasi Git blame dan lensa kode, menyusuri repositori Git, memperoleh gambaran berharga melalui perbandingan perintah-perintah, dan banyak lagi.

      Ekstensi Git Lens adalah salah satu ekstensi paling populer di komunitas, sekaligus paling andal. Sejauh ini, ekstensi ini dapat menggantikan setiap dua ekstensi sebelumnya dengan fungsionalitasnya.

      Untuk informasi “blame” (menyalahkan), pesan singkat muncul di sebelah kanan baris yang sedang Anda kerjakan untuk memberi tahu siapa yang membuat perubahan, kapan melakukannya, pesan commit yang bersangkutan. Ada beberapa potongan informasi tambahan yang muncul saat menggerakkan kursor di atas pesan ini seperti perubahan kode itu sendiri, rekaman waktu, dan banyak lagi.

      Fungsionalitas Git Blame di Git Lens

      Untuk informasi riwayat Git, ekstensi ini menyediakan banyak fungsionalitas. Anda memiliki akses mudah ke banyak opsi, termasuk menampilkan riwayat berkas, menjalankan diff terhadap versi sebelumnya, membuka revisi tertentu, dan banyak lagi. Untuk membuka berbagai opsi ini, Anda dapat mengklik teks di bilah status bawah yang berisikan penulis yang mengedit baris kode tersebut dan sudah berapa lama mengeditnya.

      Hal ini akan membuka jendela berikut:

      Fungsionalitas Git History di Git Lens

      Ekstensi ini dilengkapi fungsionalitas, dan perlu sebentar saja untuk menerapkan semua yang ditawarkannya.

      Kesimpulan

      Dalam tutorial ini, Anda telah mendalami cara menggunakan integrasi kontrol sumber dengan VS Code. VS Code dapat menangani banyak fitur yang sebelumnya mengharuskan Anda mengunduh alat terpisah.



      Source link