This is the second part of a series where I go through my monorepo setup with Github Actions deploying to Vercel. Links to all the articles in the series are at the bottom of the page.
In this article we will look closely at the build and deploy steps to the pipeline.
CI Pipeline
The main CI pipeline is handled by Turborepo. Any package which can be deployed defines a ci script within the package.json. This means that I can entrust Turborepo with only running changed applications as well as keeping the setup for each application encapsulated within.
I have recently added wasm-pack builds into my Soniq project but found that it is a nightmare trying to get rustup and cargo installed in the Vercel build alongside my yarn monorepo.
I have been planning to migrate my deployments to pure Github actions and this was the push to strap myself in and get my hands dirty.
So here is part 1 in a series where I will explain the steps I have taken to get my monorepo building and deploying efficiently with Github Actions using Turborepo and a few, key, architecture decisions.
When deploying anything other than a simple POC or personal website, a reliable application will need Environments. What is the right pattern for implementing environments for local developers as well as shared ones like staging and production?
Let’s look at how Uniform separates your configuration and content. Then look at how we can migrate both to new higher environments as a feature progresses through it’s software development workflow.
Uniform Project
Within Uniform the “Project” is the recommended way to separate configuration and content between environments. The screenshot below shows three projects used for my demo website.
I’m struck by the urgency of the state of the natural world after watching David Attenborough’s recent Netflix programs. Without action nothing will happen so I’ve been trying to think of ways in which we can be more sustainable with our technology choices. I feel focussing on three particular areas can make a significant impact, let’s look at why.
Motivation
We need a planet to live on so let’s not screw it up. This quote brings it home.
Planning out a large application can be a very daunting prospect, especially when it comes to considering all the ways in which it will be used. At Seccl, we break down our user interfaces and applications so that we are not just considering the pages.
We look at the ways people will journey through our applications; we then break it down to the ways someone might interact with a part of each journey; finally we look further into the individual pieces that you see on the screen.
You will see the term “model” used a lot when looking at JavaScript applications that deal with data. But what is a model and how do they help us architect (or structure) code to be more predictable and scaleable.
A model is a set of properties that together hold the information we need to understand a single item. An example of one of these items might be a person or an address. We could model a person by holding details of the properties: name, age and date of birth. We could model an address by holding details of the properties: street, city, country, postal code. The properties we choose will be dependent on what information our application needs.
What is Reactive Programming and Why is it helpful
One of the hardest problems to solve in programming is handling changes over time. This is because changes can come from multiple places, are unknown and will not always come in the same sequence. Even so, we still need to base logic on what is currently known and so we often find that managing these changes result in a very complex system.
We have seen the huge benefits of pure functions for creating high quality and testable JavaScript. I’ve been applying the same understanding to UI components for a while now and am seeing these same benefits. It’s useful to take a look at what makes a “pure component” and how we can change the way we build websites to realise these benefits.
A “pure function” is a function that satisfies two conditions:
Dave Taylor - Software Engineer
