Increase Your Productivity With Continuous Delivery: GitLab + Netlify
Create more valuable projects redesigning your workflow with Continuous Delivery
--
In this series of articles I am going to outline the setup, in terms of tools and flows, that I have implemented at LOW to improve the delivery process, and therefore provide high quality and projects flexibility.
The first article is a gentle introduction to Continuous Delivery; I am going to show you two powerful tools like GitLab and Netlify: what they are and how to use them together in order to step up your productivity.
To whom is this article addressed?
Small businesses without DevOps competences, but which need solid and simple procedures to share the preview of their projects internally between co-workers, and with the client.
You will learn about the following:
- Set up a git repository properly.
- Set up Netlify in order to deploy what you push on GitLab.
- Configure a custom domain on Netlify.
- Delivery your web projects following a strict flow.
The problem
Productivity is often compromised by expensive deploy procedures; in my opinion, it is one of the most critical part to resolve in every web project.
If the delivery process is manual it costs in terms of time: whenever you have to deliver a new release for the client, or just share the work-in-progress with your co-workers, you have to stop all your activities to dedicate yourself to the deployment procedure. This means waste minutes — hours if we count the entire lifetime of a project.
Moreover, and more importantly, if you do it manually your margin of error increases; therefore, increase also the probability to miss the deadline.
The solution
In order to safeguard productivity, you need to stay focused only on the code, and find issues quickly by receiving regular feedbacks on what you release. This is achievable only by delegating the delivery to someone specialised in it, someone that observers developers and deploys a new version every time they make an update in the codebase. If this someone would be a machine, it could also reduce the costs.
Well, this someone has a name, and it’s “Continuous Delivery”.
From Wikipedia:
Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.
It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production.
Now that we have understood what the benefits of Continuous Delivery are, let’s implement it!
GitLab
First of all we need a git-repository to host our source code; my suggestion is to go with GitLab:
- It’s open source.
- It’s versatile.
- It saves costs.
Also, if you want to take full control of the delivery in the future, GitLab offers powerful built-in tools for CI/CD.
In any case, Netlify works fine with GitHub as well.
Create a new repository
Let’s create a new project in GitLab, give it a name and set the visibility level based on nature of your project — choose public only in the case of open source projects, IMO.
Create a new example site
Now that we have the repository, we need an example site —we can start from this https://github.com/react-boilerplate/react-boilerplate
- Make sure that you have Node.js v8.10 and npm v5 or above installed.
- Clone the repo using
git clone --depth=1 https://github.com/react-boilerplate/react-boilerplate.git my-project - Move to the appropriate directory:
cd my-project. - Run
npm run setupin order to install dependencies and clean the git repo.
Once you have your local environment:
- Connect the local repository to the remote one:
git remote add origin git@gitlab.com:<YOUR_USERNAME>/my-project.git - Stages all changes:
git add . - Create a new commit:
git commit -m "Initial commit" - Push the commit to remote:
git push -u origin master
Fine, we have an example site on our repo.
The workflow
The workflow that we are going to follow consists in two main environments: the development and the staging. We must get into the mindset that development needs to be constantly updated, many times a day — since your team and you work on the same product, everyone must follow the work-in-progress and contribute by providing regular feedbacks to developers. Staging, on the other hand, will be shared with the client: you have to update it only when features are closed and tested.
So we need two branches: develop and master. Develop will be our default branch and development environment, master instead will be our staging.
In an ideal situation, every feature should have its own branch and, only when it gets to a stable state, merge it into develop. Remember: Develop must always be stable.
When you need to update master, create a new merge-request in GitLab from develop to master.
Configure the repository
By default, when a new repository is created, git point to the master branch. We have therefore to create the develop branch e tell GitLab that it is our main working branch.
Click on “Repository” in the menu on the left and go to “branches”. At this point, make a new branch from master named “develop”.
Once you created the branch, go to Settings › Repository. The first panel should be “Default Branch”, expand it, select develop from the drop-down menu, and save changes.
From now, whoever clones the repository will be pointed to the develop branch.
Always in Settings, there is the panel “Protected Branches”; here, as maintainer, you can choose who can change what. By default master is protected, that means only maintainers can update it, and, for our workflow, deliver new releases for the client. This decision is up to you — if you work with external developers, I suggest to keep master secure and force developers to use merge requests.
Now, it’s time to break out the big guns.
Netlify
An all-in-one workflow that combines global deployment, continuous integration, and automatic HTTPS.
Netlify lets everyone to set up continuous integration in a few clicks: just connect your repository, enter your build settings and voilà. But what makes Netlify so complete, is that it can replace your hosting infrastructure and serve sites via free HTTPS.
This is not over: Netlify supports custom domains for free, that means you can use your own domain to publish your projects.
You’re probably wondering how much it costs. Well, for our purposes the free plan is good.
Create a new site
To get started, create a new account on Netlify — you just need to sign up with your GitLab account.
When you’re done you should end up on your Dashboard; now it’s time to create your project.
Click on “New site from Git” and select your repository — in this case GitLab. Being your first time it should ask you for the authorisation to access to your account; of course you have to allow it.
Once you have done that, it should appear the list of projects on your GitLab; select the one created previously.
Last step is to tell Netlify how to deploy our site; if you use module bundlers like Webpack, almost surely you have a build command and a publish directory. In our case, running npm run build Webpack will create the static site in /build.
Now the ball is in his court — clicking on “Deploy site” Netlify starts cloning your repository; after that it downloads the correct version of Node (it supports the .nvmrc file) and finally it runs the build command. When it finishes, it gives you a unique url to preview your site — click on it to see it live!
Fine, we have our Continuous Delivery up and running.
At the moment Netlify observes changes only on master, so we have to tell it that we have others branches.
From your dashboard go to Settings › Build & Deploy; find the “Deploy contexts” panel and click “Edit settings”, here select “All” on branch deploy and then save.
From now, every branch will have its own url. Try to make a change on develop and push it , Netlify will produce a new url in this format:
https://[BRANCH_NAME]--[NETLIFY_PROJECT_ID].netlify.com
We are almost there; we have our development and our staging, which is everything we need to start work. But, honestly, we don’t like the rough url created by Netlify, isn’t it? How about personalise it?
(If you don’t own a domain, skip this section)
Create a custom url
What we want is something like this:
- staging: https://my-project.example.com
- development: https://develop.my-project.example.com
In order to let Netlify to handle DNS management for you, you have to change the nameservers on your domain provider to point at the Netlify DNS zone.
Go to your account’s Settings › Domains. Click on “Add or register domain” and enter your domain name. Verify it and add it. Ignore the second panel and click “Continue”.
Now go to your domain registrar. There should be a panel named “Nameservers” or something; to use Netlify DNS, you have to change your domain’s nameservers to the following custom hostnames:
- dns1.p06.nsone.net
- dns2.p06.nsone.net
- dns3.p06.nsone.net
- dns4.p06.nsone.net
The change of the nameservers can take some time to propagate.
Pay attention: by changing the nameservers, every DNS rules on your domain registrar will not longer be valid — from now you will have to use the Netlify DNS settings.
Fine, now go to your project’s Settings › Domain management and, on the “Custom domains” panel, click on “Add custom domain” and enter [YOUR_PROJECT_NAME].[YOUR_DOMAIN_NAME]
In my case: my-project.lorenzocadamuro.com
Now we have staging on our personal domain . Let’s do the same for development.
Always in Settings › Domain management, on the “Branch subdomains” panel, click on “New subdomain” and select the develop branch from the drop-down menu; then click “Create subdomain”.
And that’s it.
Conclusion
Since I started adopting it in projects, my team and I began working more efficiently, focusing on the quality of the code and on the best final result. Continuous Delivery will be the keystone of your development flow. It solves many of the pitfalls that developers encounter during the life of a project, by allowing agile methods and by making teams respond quickly to the changes.
