Projek Laravel dari Awal sampai Akhir

By | November 29, 2024
0 Comment

Intro: Apa saja dalam kursus ini?

Selamat datang di kursus ini tentang proses pembuatan proyek Laravel. Tujuan di sini bukanlah untuk membuat kode. Ini tentang segala sesuatu yang perlu kita lakukan dalam membuat aplikasi.

Memang, banyak kursus yang membahas cara untuk mengkode aplikasi, tetapi tidak banyak yang menjelaskan proses “dari awal hingga akhir”, jadi kami mencoba melakukannya di sini. Selain itu, kami berusaha mensimulasikan situasi bekerja dalam sebuah tim. Ini adalah keterampilan yang Anda butuhkan untuk mendapatkan pekerjaan sebagai pengembang. Dalam banyak kasus, Anda akan dipekerjakan ke dalam proyek/tim yang sudah ada dan perlu menangani proses bagaimana cara melakukan commit/push/struktur kode. Sebagai demonstrasi, kami mengambil proyek Laravel yang relatif kecil untuk mengirim newsletter dengan hanya beberapa CRUD (Create, Read, Update, and Delete).

Deskripsi lengkap proyek ini ada di pelajaran berikutnya. Saat memilih proyek, saya memiliki beberapa persyaratan dalam pikiran saya, yaitu:

  • Cukup kecil: agar kursus tidak terlalu besar (siswa cepat merasa bosan/kehilangan motivasi).
  • SaaS yang realistis: dengan multi-tenancy (pengguna melihat data mereka) tetapi tanpa pembayaran (itu akan memerlukan kursus besar terpisah).
  • Menggunakan antrean dan API pihak ketiga: ini akan memerlukan pengaturan tambahan di server lokal/staging/live dan dalam pengujian. Ide utamanya adalah Anda akan mengadopsi logika proses yang sama dari kursus ini untuk proyek yang (jauh) lebih besar.Rencana keseluruhan adalah sebagai berikut:
    1. Mengubah deskripsi proyek klien menjadi rencana tindakan teknis.
    2. Saat mengkode, menangani GitHub: cabang, isu, PR.
    3. Mengotomatiskan otomatisasi dengan CI/CD: menggunakan alat Laravel/PHP dan GitHub Actions untuk pemeriksaan otomatis.
    4. Menulis pengujian otomatis yang tepat sepanjang jalan.

Saya membagi kursus ini menjadi tiga bagian berdasarkan tonggak:

  • Tujuan 1: Dari Nol ke Staging. Menunjukkan SESUATU kepada klien untuk umpan balik pertama.
  • Tujuan 2: Dari Staging ke Live. Meluncurkan proyek setelah membuat fitur yang tersisa.
  • Tujuan 3: Pemeliharaan. “Kami sudah live – apa selanjutnya?”

Untuk saat ini, di akhir November, kami meluncurkan bagian pertama sambil mengerjakan yang lainnya dan menunggu ide-ide Anda tentang pertanyaan lain yang harus kami bahas. Jadi, jadilah aktif di kolom komentar!Di pelajaran pertama, kita akan memeriksa deskripsi proyek dan mengubahnya menjadi “apa yang sebenarnya perlu kita lakukan,” dengan tujuan mengajukan pertanyaan dan meminimalkan risiko fitur yang tidak terduga di kemudian hari.

Deskripsi Proyek Menjadi Rencana Tindakan dan Skema DB

Pertama, mari kita bicarakan sedikit tentang manajemen proyek. Membosankan, saya tahu. Kita ingin langsung terjun ke pengkodean, bukan? Tapi itulah kesalahan paling umum yang dibuat oleh para pengembang, terutama freelancer. Tahap awal proyek adalah ketika klien masih terlibat aktif, dan itu adalah kesempatan terbaik bagi kita untuk mengajukan pertanyaan kepada mereka dan meminimalkan risiko terjadinya sesuatu yang tidak terduga. Saat memulai proyek, tujuan pertama saya adalah mengubah deskripsi awal klien menjadi rencana tindakan yang dapat dilaksanakan dengan tahapan waktu yang terukur. Jadi, berikut adalah deskripsi proyek yang diberikan klien (saya) kepada kami.

Deskripsi Proyek dari Klien

LinksLetter: Ide Umum

LinksLetter akan menjadi sistem bagi orang-orang untuk mengelola tautan bookmark yang disimpan dari internet dan kemudian mengompilasinya menjadi edisi newsletter yang akan dikirim melalui penyedia kampanye email eksternal. Tidak perlu halaman utama, ini akan menjadi sistem semi-internal, jadi halaman utama harus segera mengalihkan ke formulir login. Juga tidak perlu desain yang mewah, template atau kit yang sudah ada akan baik-baik saja, asalkan tidak terlihat amatir. Sistem ini akan bekerja dengan tiga “objek”:

  • Pengguna
  • Tautan
  • Edisi newsletter

Pengguna

Pengguna dapat mendaftar, login, dan mengatur ulang kata sandi: fungsionalitas Auth yang khas. Harus ada fungsionalitas untuk mendaftar/login dengan Google. Setelah login, harus ada dua item menu: Links dan Issues. Lebih lanjut tentang mereka di bawah.

Mengelola Tautan

Pengguna dapat menambahkan tautan baik melalui formulir CRUD manual. Tautan harus memiliki field-field berikut:

  • URL (string, required)
  • Title (string, required)
  • Description (text, optional)
  • Issue ID (nullable, foreign key to “issues”, null until assigned to a specific issue)
  • Position (integer, optional, later automatically assigned but reorderable)
  • User ID (foreign key to users, automatically filled-in)

Opsi lain adalah mengimpor tautan dari API eksternal. Kami akan menggunakan Pocket untuk ini: https://getpocket.com/home Setiap pengguna dapat menghubungkan akun Pocket mereka sendiri. Di halaman “Tautan”, harus ada tombol “Impor dari Pocket” yang akan mengimpor semua tautan dengan tag tertentu dari Pocket.

Membuat Edisi Newsletter

Issue, atau dengan kata lain, “campaign” newsletter atau “curated list” adalah daftar tautan yang akan dikirim kepada pelanggan newsletter. Menu “Issue” harus berisi daftar semua isu pengguna tersebut, dan tombol “Compile new issue”. Ada tiga langkah dalam mengirim edisi newsletter:

  1. Mengompilasi tautan isu dari daftar (di menu “Links”)
  2. Menambahkan teks subjek/header/footer
  3. Mengklik “Kirim” atau “Jadwalkan”

Isu harus memiliki bidang-bidang berikut:

  • Subject (string, required)
  • Links (one-to-many relationship, by default all non-used links are added to the next issue)
  • Header text (text, optional)
  • Footer text (text, optional)
  • Links HTML text (nullable, automatically constructed but can be edited)
  • Sent at (timestamp, default NULL which then means it’s a “draft”)
  • User ID (foreign key to users, automatically filled-in)

Saya pikir alur kerja terbaik adalah mengelola tautan di bagian “Links” dan kemudian mengklik “Compile new issue” yang akan berisi semua tautan yang tidak digunakan secara otomatis dengan pratinjau daftar tersebut, pengguna hanya perlu menambahkan subjek/header/footer dan mengklik “Kirim” atau “Jadwalkan untuk Nanti”.

“Kirim” atau “Jadwalkan” akan membentuk kode HTML dari isu (hanya daftar sederhana <ul> + <li> dengan header/footer ditambahkan), menyimpannya ke dalam DB dan memanggil API eksternal untuk mengirim isu segera atau pada waktu yang dipilih jika “Jadwalkan” diklik (harus ada pemilih tanggal dan waktu).

Untuk mengirim newsletter, kami akan menggunakan API Mailchimp eksternal: https://mailchimp.com

Setelah newsletter dikirim, pengguna kembali ke item menu “Isu” untuk melihat daftar isu yang lalu. Tabel harus menunjukkan subjek dan jumlah tautan yang termasuk, dengan kemampuan untuk melihat kode HTML isu. Edisi newsletter tidak dapat diedit atau dihapus, jika pengguna ingin membatalkan newsletter yang dijadwalkan, mereka melakukannya langsung di Mailchimp.

Deskripsi Proyek Menjadi Rencana Tindakan

Berikut adalah rencana umum yang biasa saya gunakan di banyak proyek:

  • Milestone 1: Tunjukkan SESUATU kepada klien secepat mungkin
  • Milestone 2: Fitur ABC
  • Milestone 3: Fitur XYZ
  • …
  • Milestone X: Peluncuran Publik

Setiap Milestone menandakan menunjukkan sesuatu kepada klien dan mendiskusikan kemajuan untuk mendapatkan umpan balik. Daftar di atas adalah untuk disetujui oleh KLIEN. Selanjutnya, Anda perlu merincinya dengan detail teknis untuk DIRI SENDIRI. Di dalam Milestone , ada tugas-tugas nyata yang harus dilakukan. Contoh Milestone pertama:

  • Instal Laravel + Starter Kit
  • Skema basis data dan model/migrasi
  • CRUD untuk Tautan (dengan pengujian)
  • Menyiapkan GitHub dan otomatisasi dengan tindakan GitHub
  • Mengonfigurasi Pint
  • Mengonfigurasi Larastan
  • Mendeploy di server Staging dan memberikan URL kepada klien

Ini adalah detail teknis. Klien tidak (harus) perlu tahu tentang mereka, tetapi dalam pengalaman saya, tetap bermanfaat untuk menunjukkan kepada klien untuk mengesankan dengan fakta bahwa Anda benar-benar menyiapkan daftar itu.

Milestone Selanjutnya? Skema DB!

Tentu saja, jauh lebih mudah untuk merencanakan dan merinci Milestone pertama, tetapi semakin jauh ke bawah daftar, semakin sulit untuk memprediksi “ketidakpastian”.

Jadi, Anda perlu beberapa tingkat kejelasan tentang seluruh proyek. Sebuah diagram satu halaman. Dan saya menemukan selama bertahun-tahun bahwa untuk pikiran pengembang back-end kami, cara terbaik untuk menggambarkan dan memahami seluruh proyek adalah dengan memiliki skema DB.

Sebagai efek samping, ketika Anda melihat tabel/kolom, Anda akan muncul dengan pertanyaan untuk klien tentang bagian aplikasi yang tidak jelas. Jadi, inilah yang biasanya saya lakukan sebagai tugas pertama proyek. Anda dapat membuat skema DB di kertas atau di beberapa alat DB, tetapi mengapa tidak langsung menginstal Laravel dan membuat migrasi segera? Jadi, mari kita pertama-tama install Laravel.

laravel new linksletter --breeze --git
cd linksletter

Saya telah memilih dua parameter:

  • Kit awal yang saya pilih adalah Laravel Breeze: ini memiliki semua fungsionalitas Auth, dengan desain sederhana, dan tanpa menambah kompleksitas. Sempurna untuk menunjukkan “sesuatu” kepada klien.
  • Saya juga segera menginisialisasi repositori Git lokal, untuk kenyamanan. Struktur commit Git akan sangat penting sepanjang kursus ini, tetapi kita akan membahasnya lebih detail nanti.

Wizard instalasi akan menanyakan beberapa pertanyaan, seperti kerangka pengujian atau driver DB. Pilih yang Anda sukai. Itu tidak terlalu penting untuk kursus ini. Untuk catatan, saya memilih Pest dan MySQL.

Selanjutnya, kita akan membuat dua Model dengan Migrasi mereka: links dan issues.

php artisan make:model Issue -mf
php artisan make:model Link -mf

Flag f digunakan untuk Factories: kita membuatnya langsung, tetapi akan mengisinya nanti.

Jadi, berikut adalah migrasi yang saya buat:

Issues:

Schema::create('issues', function (Blueprint $table) {
    $table->id();
    $table->string('subject');
    $table->text('header_text')->nullable();
    $table->text('footer_text')->nullable();
    $table->text('links_html')->nullable();
    $table->timestamp('sent_at')->nullable();
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->timestamps();
});

Links:

Schema::create('links', function (Blueprint $table) {
    $table->id();
    $table->string('url');
    $table->string('title');
    $table->text('description')->nullable();
    $table->foreignId('issue_id')->nullable()->constrained()->nullOnDelete();
    $table->integer('position')->nullable();
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->timestamps();
});

Masalahnya adalah saya telah menghabiskan cukup banyak waktu untuk memikirkan setiap field dalam database. Misalnya:

  • Haruskah judul berupa string atau teks?
  • Haruskah migrasi links atau issues yang pertama dijalankan?
  • Bisakah deskripsi bernilai NULL?
  • Haruskah menggunakan nullOnDelete() atau cascadeOnDelete() untuk foreign key?
  • Apakah kita menggunakan soft deletes atau tidak?
  • dll.

Dan itulah poin utama dari latihan ini:

Saat bekerja pada skema DB, Anda akan muncul dengan serangkaian pertanyaan UNTUK KLIEN.

Setelah kita mengeksekusi migrasi tersebut dengan php artisan migrate, kita sudah memiliki DB nyata dan dapat menggunakan alat DB apa pun (saya menggunakan DBeaver) untuk mengekspornya ke dalam skema visual, seperti ini:

Saya cenderung mengirimkan skema ini kepada klien. Ya, saya tahu mereka tidak akan memahami istilah teknis DB, tetapi mereka akan memahami secara kasar nama-nama objek dan akan menghargai pandangan “gambaran keseluruhan” Anda.

Kemudian, dengan skema DB tersebut, Anda menambahkan serangkaian pertanyaan lanjutan dalam “bahasa manusia”:

  • Apakah field”description” tautan diperlukan atau opsional?
  • Bagaimana dengan “header_text” dan “footer_text” edisi newsletter? Diperlukan atau opsional?
  • Apakah Anda memerlukan fitur “arsip” untuk isu atau tautan sehingga pengguna dapat menghapus dan mengembalikannya? (“soft deletes”)
  • dll.

Dari sini, Anda telah mencapai tiga tujuan:

  1. Kejelasan teknis yang lebih baik untuk diri Anda sendiri.
  2. Kejelasan proyek yang lebih baik jika klien menjawab pertanyaan-pertanyaan tersebut.
  3. Kepuasan klien yang lebih tinggi karena mereka melihat kemajuan yang cepat dan dedikasi Anda terhadap detail.

Tentu saja, contoh ini dengan tiga tabel adalah dasar. Tetapi saya ingin Anda memahami ide utama dan menerapkannya pada proyek Anda nanti.

Dalam kenyataannya, skema Anda dan daftar pertanyaan akan jauh lebih kompleks, mungkin bahkan dibahas dalam beberapa pertemuan, panggilan, atau rangkaian email yang berbeda.

Sekarang, saat skema DB telah “disetujui”, kita dapat melanjutkan untuk benar-benar membangun fitur-fitur tersebut.

Di akhir langkah ini, jangan lupa untuk melakukan commit perubahan Anda ke repositori Git, yang saat ini bersifat lokal, tetapi di pelajaran berikutnya kita akan mendorongnya ke GitHub.

Berikut adalah tautan ke repositori jika Anda ingin mengikuti commit.

GitHub: Cabang, Masalah, dan CRUD Pertama

Berikutnya, kita buat CRUD pertama dari Links.

Ini adalah hasil visual akhir, setelah pelajaran ini:

Ini akan menjadi fitur daftar/buat/edit/hapus sederhana, jadi tidak banyak yang perlu dibicarakan dari sudut pandang kode. Seperti semua hal dalam kursus ini, mari kita fokus pada proses : bagian yang penting adalah kita akan menyiapkan GitHub dan cabang .

Mari konfigurasikan dan persiapkan semuanya di GitHub SEBELUM menulis kode baru.

  1. Buat repositori GitHub kosong
  2. Ikuti instruksinya untuk mendorong kode sejauh ini
git init
git add .
git commit -m "Initial Laravel Breeze and DB Models"
git branch -M main
git remote add origin https://github.com/[your_name]/[your_repo].git
git push -u origin main

Cabang pertama default dipanggil main( kecuali Anda mengubahnya ke sesuatu yang lain, tetapi saya akan menggunakan default ).

Dan sekarang pertanyaannya adalah apakah kita harus meneruskan bekerja dengan cabang itu, atau membuat cabang terpisah.

Dalam kursus ini, kami berasumsi Anda bekerja dalam tim yang beranggotakan minimal dua orang, jadi Anda perlu berkolaborasi pada beberapa fitur sekaligus, sebelum meluncurkannya.

Dengan mengingat hal itu, sangat penting untuk menerapkan perubahan main hanya jika tujuan Anda adalah menerapkannya ke server langsung.

Di waktu lainnya Anda harus bekerja pada cabang yang berbeda.

Pertama, Anda perlu membuat develop( atau kami menyebutnyadev ) cabang dari main.

git checkout -b dev

Saat ini, cabang Anda devdan maincabang lainnya sinkron, dengan versi kode yang identik.

Namun idenya di sini adalah bahwa maincabang tersebut akan dilampirkan ke server langsung , dan kode di devcabang tersebut akan digunakan untuk menguji versi “sedang berlangsung” terbaru dari proyek tersebut, pada apa yang disebut server pementasan .

Dengan kata lain, devcabang akan selalu lebih maju maindengan beberapa kode, fitur, dan perbaikan baru:

Hanya ketika Anda siap untuk meluncurkannya secara langsung, Anda akan membuat Permintaan Tarik dari dev ke main dan menggabungkan perubahan tersebut, untuk kemudian (atau segera) disebarkan.

Hanya Cabang VS “dev” untuk Fitur

Sekarang, apakah kita menulis kode dan mengirimkannya ke devcabang? Belum tentu. Ada dua strategi yang mungkin:

1. Tidak ada cabang fitur (tidak direkomendasikan): Anda bekerja pada devcabang tersebut bersama-sama dengan pengembang lain tetapi mengerjakan hal yang terpisah: fitur dan file yang berbeda dalam kode.

Mungkin nyaman, tetapi lebih berisiko: mengharuskan setiap pengembang untuk memperbarui git pullperubahan terbaru dari devcabang sebelum memulai sesi kerja mereka, untuk menghindari/meminimalkan konflik.

Dengan demikian, ada “aturan tidak tertulis” bahwa Anda harus mengirim ke devcabang hanya kode yang sudah hampir selesai, dengan fitur/tugas yang sudah sepenuhnya selesai. Anda tidak dapat mengirim “pekerjaan yang sedang berlangsung” karena pengembang lain akan bingung saat mereka menarik perubahan.

Lebih mudah diikuti dalam proyek kecil dengan sedikit perubahan kode dan hampir tidak ada konflik. Mungkin juga berhasil jika Anda bekerja sendiri.

2. Cabang fitur (disarankan): sebelum memulai pengerjaan pada fitur tertentu, pengembang membuat “cabang fitur” dengan devnama yang menjelaskan fitur tersebut, seperti “feature-links-crud” . Kemudian mereka mengerjakan cabang tersebut secara individual, tanpa melihat cabang lain atau peduli dengan apa yang dikerjakan pengembang lain.

Hingga mereka perlu menerapkan perubahannya, mereka mengirimkan Pull Request dari cabang fitur mereka devdan baru kemudian mereka melihat apakah ada konflik yang perlu diselesaikan.

Pendekatan percabangan fitur ini tidak hanya lebih tenang bagi pengembang dalam pekerjaan sehari-hari, tetapi juga memungkinkan untuk melihat dengan jelas kode mana yang termasuk dalam fitur mana. Ini menjadi sangat penting nantinya, jika terjadi kesalahan dan kita perlu melacak dengan cepat kode/cabang mana yang menimbulkan bug dan kapan.

Dalam pelajaran ini untuk CRUD Links, saya sengaja TIDAK akan menggunakan cabang fitur, untuk menunjukkan skenario pertama. Kita akan beralih ke pembuatan cabang fitur di pelajaran berikutnya.

Masalah GitHub

Saya baru saja menyebutkan manfaat melacak kode berdasarkan fitur. Namun, cara yang lebih baik adalah dengan melampirkan fitur-fitur tersebut ke suatu tugas dalam perangkat lunak manajemen proyek?

Selama bertahun-tahun, tim kami mencoba banyak alat: Trello, Asana, Monday, dan lain-lain. Namun, untuk mendapatkan urutan dari sisi teknis , tidak ada yang mengalahkan fitur internal GitHub dari GitHub Issues. Rasanya asli . Prosesnya seperti ini:

  • Anda membuat masalah GitHub dan (opsional) menetapkan rekan satu tim
  • Masalah tersebut secara otomatis mendapat nomor ID dari GitHub, seperti #123( bertambah otomatis untuk repositori tersebut ) yang kemudian dapat Anda rujuk dalam deskripsi komitmen dan PR git
  • Rekan setim tersebut membuat cabang fitur dari dev referensi nomor tersebut . Misalnya, nama cabang dapat berupa “123-links-crud”. Itu dapat membantu mengidentifikasi dengan cepat apa yang sedang dikerjakan oleh setiap pengembang.
  • Bila fitur tersebut sudah selesai, pesan komit harus berisi nomor masalah dengan tanda tagar dan kata-kata “ajaib” seperti “resolves”. Contoh pesan komit: “Links CRUD – resolves #123”.

Jika Anda melakukan semua itu, GitHub akan secara otomatis menghubungkan semuanya: di web, Anda akan dapat dengan cepat menavigasi antara masalah, permintaan penarikan, dan komitmen spesifik.

Mari saya tunjukkan semuanya dalam contoh kita.

Kami membuat masalah GitHub:

GitHub secara otomatis menetapkan ID untuknya #1. Kita akan menggunakan ID tersebut nanti saat mendorong kode dengan solusi.

Kemudian kita beralih ke dev cabang:

git checkout dev

Kenyataannya, dari sini Anda tidak boleh bekerja dengan main cabang secara langsung sama sekali. Di banyak perusahaan, cabang tersebut bahkan dilindungi dari pengiriman kode langsung ke sana. Cabang tersebut “suci” hanya untuk Pull Request ke dalamnya.

Berikutnya, kami mengkodekan fitur kami.

Kode Tautan CRUD: Tinjauan Cepat

Kursus ini tidak banyak membahas tentang pengkodean, tetapi lebih kepada proses. Jadi, saya akan meringkas secara singkat apa yang kami lakukan di sini.

Pertama, kita memiliki Pengontrol CRUD:

app/Http/Controllers/LinkController.php

class LinkController extends Controller
{
    public function index()
    {
        $links = Link::query()
            // Filter by tenant id (user_id)
            ->where('user_id', auth()->id())
            ->orderBy('id', 'desc')
            ->paginate(50);
 
        return view('links.index', [
            'links' => $links,
        ]);
    }
 
    public function create()
    {
        $users = User::all();
 
        return view('links.create', [
            'users' => $users,
        ]);
    }
 
    public function store(StoreLinkRequest $request)
    {
        $link = Link::create(
            $request->validated() + [
                'user_id' => auth()->id(),
            ]
        );
 
        // If there is no position, set it to the last
        if (!$link->position) {
            $link->position = Link::max('position') + 1;
            $link->save();
        }
 
        return redirect()->route('links.index')
            ->with('message', 'Link created successfully.');
    }
 
    public function edit(Link $link)
    {
        // Check if user is the owner of the link
        abort_unless($link->user_id === auth()->id(), 404);
 
        $users = User::all();
 
        return view('links.edit', [
            'link' => $link,
            'users' => $users,
        ]);
    }
 
    public function update(UpdateLinkRequest $request, Link $link)
    {
        abort_unless($link->user_id === auth()->id(), 404);
 
        $link->update($request->validated());
 
        return redirect()->route('links.index')
            ->with('message', 'Link updated successfully.');
    }
 
    public function destroy(Link $link)
    {
        abort_unless($link->user_id === auth()->id(), 404);
 
        $link->delete();
 
        return redirect()->route('links.index')
            ->with('message', 'Link deleted successfully.');
    }
}

Lalu kita memiliki tabel indeks sederhana:

resources/views/links/index.blade.php

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Links List') }}
        </h2>
    </x-slot>
 
    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
                    @if (session('message'))
                        <div class="mb-4 font-medium text-sm text-green-600">
                            {{ session('message') }}
                        </div>
                    @endif
 
                    <div class="mt-4">
                        <a href="{{ route('links.create') }}"
                           class="bg-green-500 hover:bg-green-700 text-white font-bold py-2 px-4 rounded">Add New
                            Link</a>
                    </div>
 
                    <table class="table-auto w-full mt-4 border">
                        <thead>
                        <tr>
                            <th class="px-4 py-2">Title</th>
                            <th class="px-4 py-2">URL</th>
                            <th class="px-4 py-2">Actions</th>
                        </tr>
                        </thead>
                        <tbody>
                        @foreach ($links as $link)
                            <tr>
                                <td class="border px-4 py-2">{{ $link->title }}</td>
                                <td class="border px-4 py-2">
                                    <a href="{{ $link->url }}" target="_blank"
                                       class="text-blue-400 underline underline-offset-3 decoration-blue-200">{{ $link->url }}</a>
                                </td>
                                <td class="border px-4 py-2">
                                    <a href="{{ route('links.edit', $link->id) }}"
                                       class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2.5 px-4 rounded">Edit</a>
                                    <form action="{{ route('links.destroy', $link->id) }}" method="POST" class="inline-block">
                                        @csrf
                                        @method('DELETE')
                                        <button type="submit"
                                                class="bg-red-500 hover:bg-red-700 text-white font-bold py-2 px-4 rounded">
                                            Delete
                                        </button>
                                    </form>
                                </td>
                            </tr>
                        @endforeach
                        </tbody>
                    </table>
 
                    <div class="mt-4">
                        {{ $links->links() }}
                    </div>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Dan formulir untuk membuat tautan baru:

Catatan: Formulir editnya identik, jadi saya tidak menampilkannya di sini.

resources/views/links/create.blade.php

<x-app-layout>
    <x-slot name="header">
        <h2 class="font-semibold text-xl text-gray-800 leading-tight">
            {{ __('Create Link') }}
        </h2>
    </x-slot>
 
    <div class="py-12">
        <div class="max-w-7xl mx-auto sm:px-6 lg:px-8">
            <div class="bg-white overflow-hidden shadow-sm sm:rounded-lg">
                <div class="p-6 bg-white border-b border-gray-200">
 
                    <form method="POST" action="{{ route('links.store') }}">
                        @csrf
 
                        <div class="mb-4">
                            <label for="title" class="block text-sm font-medium text-gray-700">Title</label>
                            <input type="text" name="title" id="title"
                                   class="form-input rounded-md shadow-sm mt-1 block w-full" value="{{ old('title') }}"
                                   autofocus/>
                            @error('title')
                            <p class="text-red-500">{{ $message }}</p>
                            @enderror
                        </div>
 
                        <div class="mb-4">
                            <label for="url" class="block text-sm font-medium text-gray-700">URL</label>
                            <input type="url" name="url" id="url"
                                   class="form-input rounded-md shadow-sm mt-1 block w-full" value="{{ old('url') }}"/>
                            @error('url')
                            <p class="text-red-500">{{ $message }}</p>
                            @enderror
                        </div>
 
                        <div class="mb-4">
                            <label for="description" class="block text-sm font-medium text-gray-700">Description</label>
                            <textarea name="description" id="description"
                                      class="form-textarea rounded-md shadow-sm mt-1 block w-full">{{ old('description') }}</textarea>
                            @error('description')
                            <p class="text-red-500">{{ $message }}</p>
                            @enderror
                        </div>
 
                        <div class="mb-4">
                            <label for="position" class="block text-sm font-medium text-gray-700">Position</label>
                            <input type="text" name="position" id="position"
                                   class="form-input rounded-md shadow-sm mt-1 block w-full"
                                   value="{{ old('position') }}"/>
                            @error('position')
                            <p class="text-red-500">{{ $message }}</p>
                            @enderror
                        </div>
 
                        <div class="mb-4">
                            <button type="submit"
                                    class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
                                Create
                            </button>
                        </div>
 
                    </form>
                </div>
            </div>
        </div>
    </div>
</x-app-layout>

Pushing to Dev Branch

Berikutnya, kami mengirim kode ke dev, merujuk ke nomor issue #1:

git add .
git commit -m "Links CRUD - resolves #1"
git push origin dev

Perhatian : tentu saja, Anda dapat mengirim beberapa komit untuk fitur yang sama, tetapi Anda tidak selalu mendapatkannya sejak awal. Jika Anda mengerjakan devcabang, cukup rujuk ID masalah yang sama di setiap komit. Dengan cabang fitur, masalah ini diselesaikan dengan cara lain, kita akan membahasnya di pelajaran berikutnya.

Dan sekarang, sebagai hasilnya kita memiliki segalanya yang saling terkait.

Kami memiliki tugas dalam daftar Masalah

Kita dapat menavigasi dari Masalah ke Komit spesifik yang menyelesaikannya

Dan sebaliknya: jika Anda melihat kode komit, ada tautan ke Masalah asli:

Ini tidak hanya membantu meninjau kode/masalah saat ini, tetapi juga membantu memahami apa yang terjadi, kapan, dan mengapa, di masa lalu. Baik dari perspektif tugas maupun kode apa yang terkait dengan fitur tertentu. Rekan satu tim dan diri Anda di masa mendatang akan berterima kasih atas hal itu.

Jadi ya, kita telah menyelesaikan fitur CRUD Links. Atau… belum. Langkah terakhir adalah menulis pengujian otomatis untuknya, dan kita akan memperkenalkan cabang fitur dengannya, di pelajaran berikutnya.

PS GitHub untuk Pengembang: Bagaimana dengan Klien?

“Catatan tambahan” terakhir untuk pelajaran ini: jika Anda bekerja dengan manajer proyek non-teknis dan pemilik produk, mereka semua perlu mempelajari GitHub dan cara membuat GitHub Issue? Atau bagaimana mereka melihat kemajuannya?

Tidak, belum tentu. Ada berbagai cara untuk mengatasinya, tetapi kami biasanya menggunakan dua sistem terpisah: perangkat lunak manajemen proyek yang berhadapan dengan klien, lalu kami hanya mengubah tugas yang dikonfirmasi menjadi masalah GitHub.

Ia tidak hanya menyaring tugas NYATA dari tumpukan “yang sedang dibahas” secara umum, tetapi juga sebagian besar klien lebih suka melihat tugas dalam “bahasa mereka”, tanpa perincian teknis. Dan ya, ia memerlukan pembaruan data dalam dua sistem, tetapi menurut pengalaman kami, itu bukan pekerjaan tambahan yang berarti, jika dilakukan dengan benar .

Selain itu, banyak alat manajemen proyek seperti Jira/Trello/dll yang terintegrasi dengan GitHub dan memungkinkan navigasi yang mudah di antara keduanya.

Namun, seperti semua hal lainnya, hal itu bergantung pada struktur dan preferensi tim Anda/klien.

Sumber : https://laraveldaily.com/

laravel
Author: admin

Full Stack Web Developer di DevApp Center. Kompetensi dalam pemrograman web, analisis data, pembangunan aplikasi berbasis GUI dengan Python, dan DevOps.

Leave a Reply

Your email address will not be published. Required fields are marked *