Continues Integration Menggunakan Travis CI dan Github Part 1

Setelah sebelumnya saya telah membahas tentang Pentingnya DevOps Dalam Dunia IT, maka pada kesempatan kali ini saya akan mencoba memberikan sedikit tutorial bagaimana cara Anda dapat mengadopsi DevOps untuk proyek Anda. Disini saya akan memulai dengan proses Continues Integration, situs yang akan kita gunakan adalah Travis CI untuk melakukan Continues Integration dan Github untuk menyimpan source code proyek Anda.

Apa Itu Continues Integration ?

Continuous Integration adalah proses menjalankan semua unit test pada kode terbaru yang diajukan untuk memeriksa apakah komponen yang baru ditambahkan tidak merusak fungsi lama apapun. Hal ini sangat penting dari perspektif pengujian dan penyebaran. Ini mencegah masalah rollbacks setelah-deployment. Mereka mengambil banyak waktu dan mengurangi keandalan produk. Untuk penjelasan  yang lebih lengkap tentang Continues Integration dapat Anda baca di Wikipedia.

Sebelum memulai melakukan proses Continues Integration, pertama-tama Anda harus menentukan jenis proyek yang akan Anda buat. Disini saya ambil contoh untuk membuat proyek aplikasi dengan Node.js. Setelah menentukan jenis proyeknya Anda harus mengetahui framework/library yang akan digunakan untuk proyek Anda, disini saya sudah menyiapkan sebuah proyek Node.js untuk mencari gambar menggunakan Google Custom Search. Untuk dapat menggunakan API dari Google Custom Search Anda perlu membuat search engine baru dan mendapatkan API key dari search engine tersebut. Silahkan menuju Google Custom Search untuk membuat search engine baru dan mendapatkan API keynya. Untuk mendapatkan sourcecode project yang saya gunakan dapat Anda temukan di Github saya  dengan nama gcs-image-api.

Perlu diingat bahwa bila Anda menggunakan proyek Anda sendiri yang tidak menggunakan Node.js tetapi menggunakan framework lain seperti misalnya .NET Core maka anda harus mengetahui build process yang terjadi, karena di Continues Integration semua build proccess dilakukan melalui terminal biasanya di Visual Studio menggunakan msbuild atau dotnet. Setiap provider biasanya menggunakan nama file yang berbeda untuk mengetahui build process yang akan dilakukan melalui terminal, namun karena dalam kasus ini saya menggunakan Travis CI maka nama file untuk mendefinisikan build processnya adalah .travis.yml.

Disini saya hanya akan fokus membuat build process yang saya gunakan, jika Anda ingin membuat untuk proyek lain Anda dapat membaca dokumentasi Travis CI di Travis CI User Documentation.
Untuk kasus kali ini proyek akan di deploy ke heroku agar dapat langsung diakses setelah proses Continues Integration selesai.

Sebelum membuat file untuk mendefinisikan build process yang terjadi biasanya Anda harus menentuka terlebih dahulu testing framework apa yang akan digunakan. Terdapat banyak sekali testing framework yang berbeda untuk bahasa pemrograman yang berbeda, namun karena disini saya menggunakan node.js yang mana di node.js menggunakan bahasa pemrograman javascript maka saya hanya memilih automated testing framework untuk javascript, untuk daftar testing framework dapat Anda temukan disini. Pada kasus ini saya menggunakan mocha dan chai dalam proses testing.

Sebelumnya saya akan sedikit menjelaskan tentang beberapa jenis Software Development Process yang sering digunakan pengembang/developer dalam pembuatan software.

Test-driven Development

Test-driven Development (TDD) adalah proses pengembangan perangkat lunak yang bergantung pada pengulangan siklus pengembangan yang sangat singkat: Persyaratan diubah menjadi kasus pengujian yang sangat spesifik, maka perangkat lunak ditingkatkan untuk lulus tes baru. Hal ini bertentangan dengan pengembangan perangkat lunak yang memungkinkan perangkat lunak untuk ditambahkan yang tidak terbukti memenuhi persyaratan.
TDD Biasanya dibagi menjadi lima tahap yang berbeda:

1. Pertama, pengembang menulis beberapa tes.
2. Pengembang kemudian menjalankan tes tersebut dan (jelas) mereka gagal karena tidak satu pun fitur tersebut yang benar-benar diterapkan.
3. Selanjutnya, pengembang benar-benar menerapkan tes tersebut dalam kode.
4. Jika pengembang menulis kode mereka dengan baik, maka pada tahap berikutnya mereka akan melihat bahwa tes mereka lulus.
5. Pengembang kemudian dapat melakukan refactor kode mereka, menambahkan komentar dan membersihkannya, karena mereka menginginkannya karena pengembang mengetahui bahwa jika kode baru tersebut merusak sesuatu, pengujian akan menjadi peringatan karena kegagalan.

Siklus terus berlanjut selama pengembang memiliki lebih banyak fitur untuk ditambahkan.

Mari kita lihat contoh bagaimana pengembang akan melakukan ini.

Katakanlah pengembang ingin menulis sebuah fungsi yang melakukan sesuatu yang sederhana, seperti menghitung faktorial. Pendekatan normal yang ditentukan oleh TDD adalah dengan menggunakan fungsi tersebut dan kemudian menyatakan bahwa hasilnya memenuhi nilai tertentu.

Dalam contoh ini, kita akan menggunakan JavaScript Testing Framework yang disebut Mocha. Tes mungkin terlihat seperti berikut:

var assert = require('assert'),
    factorial = require('../index');

suite('Test', function (){
    setup(function (){
        // Create any objects that we might need
    });

    suite('#factorial()', function (){
        test('equals 1 for sets of zero length', function (){
            assert.equal(1, factorial(0));
        });

        test('equals 1 for sets of length one', function (){
            assert.equal(1, factorial(1));
        });

        test('equals 2 for sets of length two', function (){
            assert.equal(2, factorial(2));
        });

        test('equals 6 for sets of length three', function (){
            assert.equal(6, factorial(3));
        });
    });
});

Tes pasti akan gagal karena fungsinya belum ditulis. Jadi mari kita tulis fungsi itu untuk memenuhi tes.

module.exports = function (n) {
    if (n < 0) return NaN;
    if (n === 0) return 1;

    return n * factorial(n - 1);
};

Sekarang jika kita menjalankan tes, kita bisa melihat semua tes berhasil! Beginilah cara TDD bekerja. Sekarang mari kita lihat BDD untuk melihat bagaimana perbedaannya.

Behavior-driven Development

Behavior-driven development (BDD) adalah proses pengembangan perangkat lunak yang muncul dari uji coba pengembangan (TDD). Behavior-driven development menggabungkan teknik umum dan prinsip TDD dengan gagasan dari desain berbasis domain dan analisis dan desain berorientasi objek untuk menyediakan pengembangan perangkat lunak dan tim manajemen dengan alat bersama dan proses bersama untuk berkolaborasi dalam pengembangan perangkat lunak.

Berbeda dengan TDD, BDD adalah ketika kita menulis perilaku & spesifikasi yang kemudian mendorong pengembangan perangkat lunak kita. Perilaku & spesifikasi mungkin tampak sangat mirip dengan tes tapi bedanya sangat halus dan penting.

Mari kita lihat contoh sebelumnya tentang penulisan sebuah fungsi untuk menghitung faktorial untuk sebuah angka.

var assert = require('assert'),
    factorial = require('../index');

describe('Test', function (){
    before(function(){
        // Stuff to do before the tests, like imports, what not
    });

    describe('#factorial()', function (){
        it('should return 1 when given 0', function (){
            factorial(0).should.equal(1);
        });

        it('should return 1 when given 1', function (){
            factorial(1).should.equal(1);
        });

        it('should return 2 when given 2', function (){
            factorial(2).should.equal(2);
        });

        it('should return 6 when given 3', function (){
            factorial(3).should.equal(6);
        });
    });

    after(function () {
        // Anything after the tests have finished
    });
});

Perbedaan utamanya hanyalah kata-katanya saja. BDD menggunakan gaya yang lebih verbose sehingga bisa dibaca hampir seperti sebuah kalimat.

Kemampuan untuk membaca tes Anda seperti kalimat adalah perubahan kognitif dalam bagaimana Anda akan memikirkan tes Anda. Argumennya adalah bahwa jika Anda bisa membaca tes Anda dengan lancar, Anda tentu akan menulis tes yang lebih baik dan lebih komprehensif.

Meski contoh ini sangat sederhana dan tidak mengilustrasikannya, tes BDD harus lebih fokus pada fitur, bukan hasil sebenarnya. Seringkali Anda akan mendengar bahwa BDD adalah untuk membantu merancang perangkat lunak, tidak mengujinya seperti apa yang seharusnya dilakukan TDD.