Stefan Bauer
Developer and Creator of, a simple website monitoring.
Blog Building PingPing About
"Building PingPing" was an open-source project. There have been several reasons why I discontinued creating it in public. has now a commercial version. If you have any questions about PingPing, its techniques, architecture or anything else, let me know. I might do a post about it. You can find the related sources for the old posts on GitHub.

#008 - Introducing Travis CI

Published on April 12, 2018

Introduction describes continuous integration as

A development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

A very important aspect about CI (continuous integration) that you need to understand is that it does not get rid of bugs in our application, but it does make it easier to identify and remove them.

Here comes Travis CI

Travis CI is a continuous integration tool used by many developers around the world. Services like Travis CI allow developers to test their applications when pusing code to the central repository where the code is stored. In other words, it runs the test suite each time a developer pushes new code up to the repository.

An important part of continuous integration we need to understand is that it runs the test suite for your application. In other words, we must have tests written for our app to verify it works as it's expected. Thanksfully, we've already written a few tests, and we'll continue to write even more as we go on.

Setting up Travis CI in our repository

Getting started with Travis couldn't be easier. We simply need to login with our Github account, select the repository we'd like to activate, and we're pretty much ready. Travis is free for all open source projects. If you want to use it with a private repo, you'll need to sign up for one of their plans. In our case, since PingPing is public, we can get started for free.

After logging in with our Github account, we can see a dropdown of all our public repositories. We'll select the PingPing repository to activate it with Travis.

Travis CI Dashboard

Also in the dashboard we'll see after activating our repository, a history of all the builds Travis did, their status, and other additional information about them.

Travis CI build history

Let's set up our repository for Travis CI

Now that we've selected the repository from the Travis dashboard, we need to add a couple of new files in our repository so we can have a bit more of control of what Travis is doing.

We will create two files. A .env.travis file that will have Travis specific environment variables and a .travis.yml file that will have some configuration settings for Travis.


--- /dev/null
+++ b/.env.travis
@@ -0,0 +1,6 @@

In this file we only added the required configuration so that Travis can test our Laravel application. We set our connection to be mysql, specified the database name and the username and password to connect to it. To be honest, we could use sqlite as well, but I prefer to have quite the same environment as on my production machine later.


--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,21 @@
+language: php
+  - 7.1
+  - 7.2
+  - cp .env.travis .env
+  - mysql -e 'create database pingping_test;'
+  - composer self-update
+  - composer install --no-interaction
+  - php artisan key:generate
+  - yarn install
+  - yarn run prod
+  - vendor/bin/phpunit
+  directories:
+    - vendor

In this configuration file, we can specify a few options that are very important for Travis to do its job. First of all we need to specify the language our project is written in, in this case, since we are using Laravel, we set it to php.

We also specify what versions of php we'd like Travis to test our code against. In this case we are only worried about version 7.1 and 7.2 of the language.

The before_script key is very important since it tells Travis what commands it needs to run to get the app ready before running the tests against it. First of all we are creating our our .env file by copying the .env.travis file we created earlier, without this file our application will not work. We also created the database we specified in our .env.travis file, update composer and run the composer install --no-interaction command to install all of our dependencies. We also run php artisan key:generate to generate our secret application key, we install our javascript dependencies and then compile them with the yarn run prod command.

You might be asking why are we installing and compiling our Javascript dependencies if we are only running php tests with Travis. Well, the answer is pretty simple. Laravel will throw an error if it doesn't find a public/mix-manifest.json file and this file is generated when you install and compile your assets with Laravel Mix.

What Now?

Now that we have Travis setup in our application, it will check all new commits and PRs against our test suite. We'll add a little badge Travis CI provides so that we can easily see what's the status our application, it will show us if the last build it did against our application was successful or not. We'll add a file so that anyone who visits the repository can see the status of our application.

--- /dev/null
+++ b/
@@ -0,0 +1,4 @@
+# PingPing - Simple Website Monitoring
+[![Build Status](](
+This is a simple website monitoring built in public by [@stefanbauerme]( at [](

Now that we have Travis CI ready in our repository, we can continue to work with an assurance that our application is being tested every time we update anything in our repository.

Thanks for keeping up with all the blog posts, I hope you enjoyed this one. In the next episode we'll build the landing page for PingPing.

Imprint Cookie Policy Privacy Policy
Proudly hosted with Vultr