React and CI/CD – From 0 to Released

• 9 minutes READ

CI/CD has become the beating heart of any software team. A well-refined CI/CD process results in a frictionless path to live. In turn, this results in smaller, simpler releases that enable teams to test out experiments, react to bugs and de-risk their deployments. It is the silent engine that drives your product forward.

So here, I thought I’d write a tutorial, from absolutely nothing to a simple react application running in AWS that can be accessed by the world. Let’s stop talking and start deploying!


  • You’ll need an AWS account. Follow the documentation to get ahold of your access and secret keys. Keep ahold of them, you’ll need them for later. If you have access to a free tier, this won’t cost you a penny. If not, this will cost you a few dollars at most.
  • An Account on Github.
  • You’ll need a trial account on Buddy. This is the CI/CD solution we’re going to be using. It’s cool, you’ll see why later. The trial is completely free and you can sign up using your Github account (which will make the later part of this tutorial easier).

Create your “Server”

AWS has a storage service named S3. Think of it like a file system that you don’t need to set up. It has a cool feature. You can switch an S3 bucket into HTTP access mode and treat it just like a website server. At the end of this article, we’ll discuss some options for making this entirely production-ready.

First, go to the S3 service in the AWS console. You should be able to create a brand new S3 bucket. Follow the instructions and give your bucket an appropriate name (I went for bucket-mcbucketface123 for obvious reasons). Don’t bother turning on cloudwatch metrics or encryption for now, we’ll discuss these later on.

Unblock public access

It’s important you untick “Block all public access”

After you’ve completed your bucket, you should be taken to the S3 services page where you’ll see your glorious new S3 bucket.

S3 Bucket

Click on your bucket and you’ll be shown the items in your bucket, which should be empty. Look at the tabs at the top of the screen and you should find “Properties”. Click on that tab, then click on “Static Website Hosting”. This will open up the dialog and you’ll see an option to “Enable Static Website Hosting”

Static Website Hosting

The default configuration is perfect here.

Let’s run a little test. In your local file editor, create the following HTML file and upload it to your S3 bucket with the name index.html.

        <title>My Site!</title>
        <h1>This really is a great site</h1>

When you’re uploading your file, make sure you give public read access to your object.

Public read access

Now click on the link that you can see on the static website hosting screen and, with a bit of luck, you should see:

Basic Site on S3

Quick Recap before we move on

There were a few steps here so let’s just quickly recap and make sure we’re happy. So far, we have:

  • Created an S3 bucket, which is a simple file system that AWS provides
  • We have configured that S3 bucket to behave like a website server
  • We have upload some test HTML to ensure everything is working

We have a server! Next, we need to create an application to deploy. Then, we need some way of deploying it, which is where our Buddy comes in.

Create your App

NOTE: If you already have an app deployed to Github that you’d like to deploy, you can skip right over this part. You simply need to ensure that the root HTML file in the final bundle is called index.html, which it usually is.

Creating a React app, in the olden days, used to be a gauntlet of pushing Javascript configuration together in the same place. Now, the good folks at Facebook have made create-react-app so we don’t need to worry about it. To install it, simply run:

npm install -g create-react-app</code>

You’ll need at least Node version 8 to run this. I’d recommend simply getting the latest stable release, to avoid any headaches going forward. Once you have it installed, simply run create-react-app my-app and watch the magic…

Create React App

Your app is being created in a folder for you, before your very eyes!

If you’ve not used this tool before, it has a plethora of functionality attached to it. We’ll not be doing too much with it in this tutorial, but the documentation is very good.

For now, test that everything is working by running npm start from inside your new application. This should start up a server and open up your default browser at https://localhost:3000. After a few seconds, you’ll see the boilerplate react application

Boilerplate React App

Later on in this tutorial, we’ll make some edits to this application so we’re not stuck with the stock code. For now, we’ve got a working application. Let’s get it into Github.

Upload your Application to Github

You’ll need to put your code in some place that is accessible to our CI/CD solution. A convenient place for this is Github! So what do we need to do? Navigate to Github and click on that super satisfying green button.

New Repo Github

This button is always the start of something fun.

The only bit of configuration that is important is the README config. Make sure it is unticked so that Github won’t make one for you. The same goes for .gitignore files and a license file. For example, here is my configuration:

New Repo Config Github

Now you’ve got your repository, you need to push your local code to it. Go back to your boilerplate react application and run the following commands:

git init
git remote add origin <your git repository url here>
git push --set-upstream origin master

With a bit of luck, after you’ve ran your last command, you should see something like this:

Git Push

Now navigate back to your application on github. All of your code should be there. We now have an application that has been pushed up into a version control solution. We’re only one step away from having a full CI/CD pipeline in place!

Configure your CI/CD Pipeline

Navigate to Buddy and login using your Github account. Click on “New Project” and make sure that “GitHub” is listed as the source of your repositories. There are lots of other options here by the way, but Github is the one we’re going with.

Buddy Github

Find your repository, click on it and watch the magic happen. The next screen is one of Buddy’s more impressive features. It will auto-detect the type of project automatically. This will make building and deploying your app far more intuitive.

Buddy React

Click on “Add a New Pipeline” and supply the following configuration. I’ve spent a bit of time playing with Buddy and this is my favourite setup:

Buddy Pipeline

Add your new pipeline and it’s time to start adding some actions! So what steps should our pipeline have?


First, we need to test the code that’s on our master branch. All good CI/CD pipelines use tests as an automated quality gate and I see no reason to break from tradition now. To do this, you’ll notice that Node.js has already been detected for you. This is part of Buddy’s intuitive setup.

Node JS is automatically detected

On the next screen, you only need to make one minor edit to the auto-generated test command. You’ll see on your screen that npm test will already be present. Because of a quirk of the create-react-app command, you simply need to set a variable before this command is ran. Your configuration should look like this:

Buddy NPM test config

Then click “Add this Action”. You’re done with making your test step. Let’s give our pipeline a Run now to see what happens. On the top right of the screen should be a “Run Pipeline” button.

Pipeline ran with just test step

When the output is ran, the step should be successful and you’ll see that the one autogenerated test was ran successfully.

NPM Test Success on Buddy


In much the same fashion as before, we now need to package up our application. This is another action that we’re going to add into our pipeline. You’re going to follow all of the previous steps, except when you’re entering in your command for NPM, your action should look like this:

NPM Build on Buddy

This is another script that is provided by the create-react-app tool. It will automatically create an optimised bundle and index.html that you can publish onto your website server. We also don’t need the npm install command, since this was ran in the previous step. Save that action and run your pipeline again. Everything should go green. We’ve got a working build step and all we need to do is get our files into S3.


This final step needs a little configuration. As with all the other steps, you should create a new action and scroll down for the S3 integration. Once you’re there, you’ll need to set up your AWS account. This is easy to do. Click on the “Account” dropdown and select “Add Another AWS Account”.

Buddy AWS Account Dropdown

Name your AWS account integration, paste in your access and secret keys into the dialog and save it. Your Buddy account is now hooked into your AWS account! Once you’ve saved, you’ll notice that your S3 buckets are now populated in the list.

S3 Buckets listed in buddy

Finally, your S3 configuration in Buddy should look something like this:

Deploy Configuration in buddy

Notice that we’ve set the build/ directory as our source path. This is the content we want to push out into our S3 bucket. To make this easier, you can click on the browse link and it will show you all of the artifacts from the previous build step, so you don’t need to memorise paths or anything like that.

Navigate to the “Options” tab and set the ACL drop-down to PUBLIC_READ. This will ensure that the objects you’re uploading into your S3 bucket are accessible to the public. Finally, untick “Skip Content Type setting” so that your browser knows what to do with the files, once it has them.

Public Read S3

Just copy this, basically

Save your action and you’ll be presented with a dialog. This is simply saying that, at the moment, nothing has been deployed to your server. It gives you the option of handling it yourself or rerunning the whole pipeline.

Rerun the whole pipeline and when it’s finished, navigate back to your S3 website and there you have it! Your boilerplate react application has been deployed.

Testing it out

Let’s make a change to our application and give our new CI/CD process a run through. Go back to your app and make whatever change you like. Be bold, be expressive. I’ve spent most of my life as a backend developer so I lack both of these qualities. I’ll do something suitable.

Code changed

Commit, push onto your master branch and don’t do anything elseBuddy will automatically build and deploy your new revision into your S3 bucket. Give it a few minutes and navigate back to your website:

React deployed change

Retracing our Steps

We’ve been on quite a journey over the course of this tutorial, so let’s describe what we did at a high level.

  1. We made an S3 bucket that can be read publicly and is setup for static website hosting
  2. We made a basic react app using create-react-app and we pushed it into Github
  3. We made a continuous deployment pipeline using Buddy that will test, build and push our code into S3 every time we push onto master.

Making this Production Ready

If you have a small, simple website, this setup will likely work fine for you. If you want to extend this into something a little more secure, this can easily be done. Here are some pointers.

  • If you’re expecting high traffic volumes, you can use AWS Cloudfront as a CDN to ensure consistent page load times for your site.
  • You can turn on versioning in your S3 bucket so if something goes very wrong, you can always manually revert.
  • You can turn on static encryption in your S3 bucket if there are some things in there you’d like to keep hidden and not publicly accessible, such as config files.
  • Enable Cloudwatch metrics for your S3 bucket so you can monitor traffic to your site.
  • Set up a domain name using Route 53 so people don’t need to navigate to a slightly ugly S3 bucket.

The list is endless, but at least now you’ve got a working basis from which to develop your React application, using a highly cost-effective hosting and storage method and a very intuitive, easy to understand CI/CD solution.

Chris Cooney

Chris has been a software engineer for five years, working across multiple industries and with various technologies. His recent focus has been on automation and developer experience.

Posts by Chris Cooney