DevOps your personal website and code it directly on your iPad (or any Mobile Device)

Luca Cesarano
5 min readAug 28, 2021

--

It’s been a while. I recently bought an iPad Pro and I’m in love with it. It’s fast, the M1 does a great job, the physical keyboard with trackpad is super and I just love it. Well, the iPad is a great device for many things but not very good for one feature I really hoped I could exploit it for, developing stuff!

iPad OS was just not made for that, I hope Apple will unleash its potential and makes it a great products for engineers, developers and whoever wants to nerd a little on it.

Anyway, part of my job in the company I work for is being a DevOps Engineer and guess what.. DevOps and more specifically, CI/CD, allows us to use our iPad like a real development machine (well, kind of..).

So, let’s get to the point. My website, https://lucacesarano.com is now entirely customizable directly from my iPad, thanks to Gitlab.com and its CI/CD repository features. So, if I need to modify my website, I don’t need to care anymore about having a machine with npm, firebase, credentials setup and the repository cloned but I just need my Tablet or my Phone.

Gitlab allows us to rent (for free) runners, which are linux-based machine (more precisely, containers) that can run any custom script we want and can be triggered by a simple push to our repository.

So… the workflow is the following:

  1. We push the modified code of our website on Gitlab;
  2. Gitlab detects the push, launch a runner that triggers a pipeline that build and deploy our project;
  3. After its execution, the website is updated.

Additionally, I created a https://beta.lucacesarano.com for developing purposes to test features before releasing on my main website.

The general schema is:

Last but not least, Gitlab has a Web IDE (or Gitpod) to directly work on our repository as if it’s downloaded on our computer but entirely remotely.

In this guide I’ll show you how to do all of this (and it’s all free!)

Requisites may vary a little, depending on your current setup, mine is:

  • My domain provider is CloudFlare (you can use whatever you prefer)
  • My website is hosted on Firebase (Spark Plan is free, but you can use whatever you prefer, even your Raspberry!).
  • I configured on Firebase one Project with two sites, lucacesarano.com (production environment) and beta.lucacesarano.com (development environment).
  • My website was made in React, so I use npm to build and firebase-tools to deploy.

First step is to create a repository on Gitlab. You can start from scratch or you can import it from Github if you have it hosted there.

Click on the Web IDE button to start to work on the repository:

Now it’s time to create the two pipelines required for this project. My suggestion is to create first the one for Master, make it work, and then add the one for Develop. KISS rule must always be followed in IT.

A pipeline on Gitlab is written in .yml, which is quite a cool choice (imho) for writing this kind of stuff.

create a .gitlab-ci.yml:

stages:
- build
- deploy

include:
- local: .master.gitlab-ci.yml

Inside this file we define the stages of our pipeline, which is going to be two, and the file that contains the code of the pipeline.

create a .master.gitlab-ci.yml

prod:build:
stage: build
image:
name: node
only:
refs:
- master
script:
- npm install react
- npm run build
artifacts:
paths:
- ./build
expire_in: 1 hour

prod:deploy:
stage: deploy
image:
name: node
dependencies:
- prod:build
only:
refs:
- master
script:
- npm install -g firebase-tools
- firebase use "lucacesarano-com" --token "$FIREBASE_TOKEN"
- firebase deploy -m "Pipe $CI_PIPELINE_ID Build $CI_BUILD_ID" --only hosting:lucacesarano-com --non-interactive --token "$FIREBASE_TOKEN"

The build stage runs a node docker container (if you don’t know about docker and microservices, you should study it RIGHT NOW). The ‘only’ field defines that the stage is going to be running only in the ‘master’ branch.

The script is a simple shell script that install react and builds the project, and as output exports an artifact named ./build available for a hour; this is necessary in order to pass the content of the ./build folder to the next stage. Elsewhere, the deployment wouldn’t find the folder and it would fail.

The deploy script differs in the script itself. We don’t need react but firebase-tools and the instructions for deploying the website. If some of you are confused about $FIREBASE_TOKEN, it’s a environment variable that can be setup in the repository CI/CD settings. It’s important to not write it in plain text but to hide it this way for security reasons. If you don’t do it, everyone could deploy stuff on your website (and you don’t want that, right?)

After this, pushing some code on your repository (master branch) triggers a pipeline that should look like this:

Try to explore, open the steps and check the logs. Debug if there are mistakes and be patient, the first time is always the hardest.

Now that we completed with the Master part, we simply need to do the replicate the whole scenario for the develop branch.

Setup a second-level domain for your development website (I used beta.lucacesarano.com). You need to set it up on your Domain Provider and on your Hosting Service.

After done that, you can create a new pipeline for develop. Let’s start it!

Open .gitlab-ci.yml and add a new row for your new pipeline

include:
- local: .develop.gitlab-ci.yml
- local: .master.gitlab-ci.yml

Create a .develop.gitlab-ci.yml:

develop:build:
stage: build
image:
name: node
only:
refs:
- develop
script:
- npm install react
- npm run build
artifacts:
paths:
- ./build
expire_in: 1 hour

develop:deploy:
stage: deploy
image:
name: node
dependencies:
- develop:build
only:
refs:
- develop
script:
- npm install -g firebase-tools
- firebase use "lucacesarano-com" --token "$FIREBASE_TOKEN"
- firebase deploy -m "Pipe $CI_PIPELINE_ID Build $CI_BUILD_ID" --only hosting:beta-lucacesarano-com --non-interactive --token "$FIREBASE_TOKEN"

The code is exactly the same as the master pipeline, it differs only in a few things.

Now run the code on your Develop branch and a pipeline will be triggered on it.

If everything went fine, the website should be updated accordingly.

A nice to have feature could be to block push on the master branch. If you want to deploy stuff on your main domain, you should be able to promote it from the develop environment, so via a Merge Request done in Gitlab, as described in the diagram in this Medium.

Hit me up if you need some suggestions, bye!

--

--