Setting Up a GitLab Page

Before we dig into the "how" of getting this project set up. I think it is important to understand the "why" we use source control. For those who are solo developers on side projects, source control may seem like a terrible burden. First, you have to set up an account with some provider. Or you have to install some additional software on your machine. Maybe you have to do both. Some additional steps have to take place to start a project. Additional steps after implementing changes to a project. Maybe it is another thing to learn on top of the work you are developing. Or maybe this is the first you are hearing of source control. For any of the reasons above, the benefits outweigh the few additional tasks.

Here is my ranking of why to use source control on solo projects:

1. Good practice for a professional career or professional aspirations
2. Aides in developing a process of incremental improvements to project
3. Access to free build and deployment tools
4. Allows for experimentation without impacting base feature development
5. It can save you from a hard drive failure
6. You can bounce between several development environments without a jump drive
7. Ability to rollback issues
8. History of changes
9. The software is free

Here are some tips for getting started:

• Before starting the project, initialize the source control repository
• Familiarize yourself with ignoring files that do not belong in source control
• Try out a couple of source control vendors, they are not a one size fits all
• Make small changes to the project (less than 10 files if possible), test the changes, and commit them
• Push to the remote repository early, push often
• Try some of the tools available to assist in streamlining the commit and push activities

Bringing It All Together

This was quite easy to complete. If you are familiar with git and have used it for one project, you can do this too. Now I had the sample Hexo project that is created after issuing the hexo init command. I already knew that GitLab would be my target for a repository. After reading some quick documentation about GitLabPages I knew I wanted to have this hosted at https://andrewschwabe.gitlab.io for a clean and easy appearance. All it takes to do this is to name the project accordingly, andrewschwabe.gitlab.io. With the project created GitLab gives you all the commands, you need to initialize the remotes. Easy, copy some of the commands execute them in a command terminal. Project is created, remotes are set and the repository is populated. Now, the issue, how does one get the build artifact? Then, how does one deploy it to GitLabPages?

After digging into those questions some, they were easily answered by one sample project. The main interest in this repository is the .gitlab-ci.yml. Copying this file, adding it to my repository, commit and push. Next, think I know https://andrewschwabe.gitlab.io is working like a charm.

That was all there was to it! These tools are pretty amazing. For the price of 45 minutes, a project went from a development machine to hosted one. All using free tooling while still following best DevOps practices. Next, let's break down the .gitlab-ci.yml to understand what it is doing.