A React + IIS Website GitLab CI/CD YAML Example

GitLab CI/CD is a pretty big part of my deployment strategy with the React websites that I build. My current engagement has me pushing to a Windows IIS server via GitLab’s continuous integration/deployment, so I wanted to post an example of the YAML file that makes it all happen. Without going into the in’s and outs of how GitLab CI/CD works, here’s an example of my GitLab YAML template that I use for React websites on IIS servers.

There are a couple prerequisites that need to be in place if you’re going to use this file:

  1. Starting off this build server is a windows machine, any other set up requires a few updates.
  2. The build server needs to have NPM, NodeJS and MS Web Deploy V3 installed. Install MS Web Deploy on the build and web server.
  3. $CI_USERNAME and $CI_PASSWORD are GitLab secrets. CI_USERNAME should have access to the IIS server.
  4. The IIS website is set up for Basic Authentication permissions.

That’s it. Let me know if you run into any issues or have questions.

stages:
 - build
 - deploy

before_script:
 - echo BEGINNING

#------------------------------------------------------------------------------------
#------------------------------------------------------------------------------------

#----------------------------
# Build Website Pieces
#----------------------------
build_web_production:
  stage: build
  script:
    - $Env:Path += ";C:\Program Files\nodejs"
    - npm install 
    - npm run build
  only:
    - main
  artifacts:
   paths: 
    - "$CI_PROJECT_DIR/build"
  environment: 
    name: production
    url: http://example.com
  tags:
    - shell
#----------------------------
# End Build Website Pieces
#----------------------------   

#------------------------------------------------------------------------------------
#------------------------------------------------------------------------------------

#----------------------------
# Deploy Website Pieces
#----------------------------
deploy_web_production:
 stage: deploy
 only:
  - main
 script: 
  - $Env:Path += ";C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\"
  - msdeploy -verb:sync -source:contentPath="$CI_PROJECT_DIR/build" -dest:contentPath="IIS_WEBSITE_NAME",ComputerName="https://IISSERVER:8172/msdeploy.axd?site=IIS_WEBSITE_NAME",UserName=$CI_USERNAME,Password=$CI_PASSWORD,IncludeAcls='False',AuthType='Basic' -skip:objectName=filePath,absolutePath=.*web\.config -enableRule:AppOffline -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -allowUntrusted -userAgent="VSCmdLine:WTE1.0.0.0"
 dependencies:
  - build_web_production
 environment: 
  name: test
  url: https://example.com
 artifacts:
  paths: 
   - "$CI_PROJECT_DIR/build"
 tags:
  - shell

 

Gitlab

My Top 5 Reasons To Start Using CI/CD

For the first half of my career we moved code from our local machines -> dev -> test -> production the old cowboy way, just by copy & paste from one environment to the next. It’s quick and easy but also riddled with holes. Now we’ve got better ways of doing things with processes like CI/CD and source control systems like Gitlab and Github. Here are my top five reasons why you should have a CI/CD process or pipeline set up into your development workflow:

  1. Each commit can be traced to a specific environment allowing developers to see what code is in production or test at any given time.
  2. If you’re pasting files around, you can easily blow away or overwrite something you didn’t mean to.
  3. CI/CD pipelines let you can roll back commits and changes with the click of a button if you break something. Thus keeping you from scrambling to find that backup folder you created (or didn’t) before moving the code to production.
  4. Check in your code and forget. CI/CD pipelines will automatically move your changes to your environments for you.
  5. Pipelines will run unit and integration tests before deploying code. If the tests fail the migration is halted so breaking changes never make it to production.

This getting started guide for Gitlab is a good place to start with CI/CD.

Add A New Git Remote Repository

Working with different clients I often end up with multiple Git remote repositories. When I start a new project with a client I create the initial repository in my Gitlab called origin and if the time comes I will add another remote repository in the client environment with the name of the client clientABC. This is how to add a new Git remote repository in addition to your default Git repository.

Add the new remote repository using the git remote add command.
git remote add clientABC https://gitlab.com/clientABC/exampl-repo.git

Then when pushing or pulling from the different remote repositories make sure to include the appropriate remote name when running the commands. For example, when pulling from origin dev branch use git pull origin dev. And if you want to push your changes up to the new client remote use git push clientABC dev.

Remove Passwords From Git History

Every once in a while you’ll check in a key or password into a git repository by mistake. Not to worry, there’s a great utility that can erase the values from history for you. You can delete the file or update the text from the current HEAD but the value still exists in your branch history so you need to go further to remove the value.

Luckily there’s the BFG Repo-Cleaner utility tool that goes through your git history and updates all references of the private value and replaces it with **Removed**.

Here’s how to use the BFG Repo-Cleaner to remove passwords from your git history. The BFG Repo-Cleaner is a Java file that can be saved to your local machine and run against your cloned git repo.

  1. Start by downloading the BFG Repo-Cleaner .jar file to your local machine. I saved mine to a folder called bfg on my D: drive – D:\code\bfg.
  2. Create a passwords.txt file that lists the passwords/keys you want to remove from your git repository and save to the same folder as the BFG Cleaner. The passwords.txt file is just a list of different passwords/keys that you want to remove from the repository.
    password1
    password2
    keyvalue123
  3. Clone your repository using the –mirror flag and make a full backup of the repo just in case something breaks.
    $ git clone --mirror https://github.com/clintmcmahon/delete-passwords.git
  4. Open command prompt and run the following command
    $ java -jar d:\code\bfg\bfg-1.13.0.jar --replace-text d:\code\bfg\passwords.txt d:\code\delete-passwords.git
  5. Move into the cloned git folder and run the following command
    $ cd delete-passwords.git
    $ git reflog expire --expire=now --all && git gc --prune=now --aggressive
  6. And finally push your changes back to the remote repository
    $ git push

That’s it. If you go into your repository now you will see that all references to your values from the passwords.txt file will now be replaced with **Removed**. This is just the tip of the utilities ability, there are more examples and other documentation on at the BFG Repo-Cleaner project Github page.