DEV Community: Anderson Chinedum

The DevOps Toolchain Every Beginner Needs

Anderson Chinedum — Mon, 05 Oct 2026 18:16:35 +0000

When I started getting deeper into DevOps, I kept coming across the same tools again and again: Git, Docker, Terraform, Azure CLI, GitHub CLI, and others.

Knowing their names was one thing. Understanding why I needed each one and how they fit into an actual DevOps workflow was different.

Recently, I decided to properly set up the toolchain I will be using for my DevOps work on Windows. I expected it to be mostly downloading applications and checking their versions.

It wasn't quite that simple.

Along the way, I ran into issues with Docker not connecting to its engine, Terraform not being recognized outside its folder, Azure CLI not appearing in an already-open terminal, and GitHub CLI working in PowerShell but not immediately inside VS Code.

Working through those problems actually helped me understand the tools better than simply installing them without any issues.

In this article, I'll walk through the DevOps toolchain I set up, what each tool does, how I verified that everything was working, and some of the problems I encountered along the way.

One thing I should make clear from the beginning: there isn't one universal DevOps toolchain that every engineer uses.

Different teams use different cloud providers, CI/CD platforms, container tools, and infrastructure technologies.

For the Azure-focused environment I'm currently working with, these are the tools I started with:

Git
Azure CLI
Docker
Terraform
Visual Studio Code
GitHub CLI

By the end of the setup, I wanted more than six installed applications. I wanted a workstation where I could actually use all of them from the terminal and start connecting them together in real DevOps workflows.

What exactly is a DevOps toolchain?

DevOps is not one application.

It is a workflow made up of different tools that handle different parts of building, testing, deploying, and managing software.

The easiest way I found to understand the tools was to stop looking at them individually and think about how they connect.

For the toolchain I set up, the flow looks roughly like this:

VS Code
   ↓
Git
   ↓
GitHub
   ↓
Docker
   ↓
Terraform
   ↓
Azure

VS Code gives me the environment where I work.

Git tracks the changes I make.

GitHub gives me somewhere to store and share those changes remotely.

Docker packages applications into containers.

Terraform lets me describe infrastructure using code.

Azure CLI lets me interact with Azure directly from the terminal.

GitHub CLI also gives me another way to work with GitHub without constantly going back to the browser.

Each tool solves a different problem, but together they form the beginning of a practical DevOps environment.

Git: tracking changes from the beginning

Git was already installed on my system, so the first thing I needed to do was verify it.

git --version

My system returned:

git version 2.56.0.windows.1

Git is a version-control system.

Its job is to track changes made to files over time.

That becomes important very quickly in DevOps because almost everything eventually becomes a file that needs to be tracked: application code, Dockerfiles, Terraform configuration, CI/CD pipelines, documentation, and more.

If something changes, Git gives me a way to know what changed, when it changed, and which version I am currently working with.

This is also why Git usually sits near the beginning of a DevOps workflow.

Before automating or deploying something, it makes sense to first have proper control over the files being changed.

Azure CLI: working with Azure from the terminal

The next tool was Azure CLI.

Azure has a graphical web portal where resources can be created and managed, but DevOps workflows should not depend entirely on manually clicking through a dashboard.

Azure CLI gives me a way to interact with Azure directly from the terminal.

On Windows, I installed it using WinGet:

winget install --exact --id Microsoft.AzureCLI

The installation completed successfully.

Then I ran:

az version

and got this:

az : The term 'az' is not recognized as the name of a cmdlet,
function, script file, or operable program.

At first, I thought something had gone wrong with the installation.

But Azure CLI had actually installed correctly.

The problem was that I was still using a PowerShell session that had already been open before the installation.

I closed PowerShell, opened a fresh session, and tried again:

az version

This time it worked and returned the installed Azure CLI version.

That taught me something useful very early in the setup:

Installing a command-line tool does not always mean an already-open terminal will immediately know where to find it.

Sometimes the terminal simply needs to be restarted so it can pick up the updated environment.

Docker: having the CLI is not enough

Docker was one of the most interesting parts of the setup.

Docker is used to package applications into containers so that they can run more consistently across different environments.

I installed Docker Desktop and checked whether the CLI was available:

docker --version

The command worked:

Docker version 29.8.2

At that point, I assumed Docker was ready.

Then I ran:

docker run hello-world

and got an error:

failed to connect to the docker API at
npipe:////./pipe/dockerDesktopLinuxEngine

The system cannot find the file specified.

This was where I learned the difference between having the Docker command installed and having the Docker engine running.

The Docker CLI was available, but Docker Desktop had not fully started the engine the CLI needed to communicate with.

After starting Docker Desktop properly, I ran:

docker info

This time I could see both client and server information.

Then I tried again:

docker run hello-world

Docker pulled the image and successfully created the container.

Hello from Docker!

This message shows that your installation appears to be working correctly.

That test was more meaningful than simply checking the version.

docker --version proved that the command existed.

docker run hello-world proved that Docker could actually contact the daemon, pull an image, create a container, and run it.

Terraform: when the application works but Windows cannot find it

Terraform gave me a completely different problem.

Terraform is an Infrastructure as Code tool.

Instead of manually creating every infrastructure resource through a cloud dashboard, Terraform allows infrastructure to be defined in configuration files.

For Windows, I downloaded the Terraform ZIP file and extracted the application into a folder.

Then I tried:

terraform -version

PowerShell returned:

terraform : The term 'terraform' is not recognized as the name
of a cmdlet, function, script file, or operable program.

At this point, I needed to know whether Terraform itself was broken or whether Windows simply did not know where the application was located.

I changed into the folder where I had placed Terraform:

cd C:\Users\<USER>\Documents\Terraform

Then I ran:

.\terraform.exe -version

This worked:

Terraform v1.16.5
on windows_amd64

That told me immediately that Terraform itself was fine.

The problem was PATH.

Windows uses the PATH environment variable to know which directories it should search when I enter commands such as:

git
docker
terraform
az

I added the Terraform folder to my user PATH.

After closing PowerShell and opening a new session, I ran:

terraform -version

again.

This time it worked from anywhere.

That was probably the clearest lesson I got from the entire setup about how command-line tools actually become available system-wide.

VS Code: where everything starts coming together

VS Code was already my main development environment, so there wasn't much installation work to do here.

I verified that its CLI command was working with:

code --version

The useful part for me was seeing how all the other tools could come together inside the VS Code integrated terminal.

Instead of constantly switching between different applications, I could use Git, Azure CLI, Docker, Terraform, and GitHub CLI from the same workspace where I was editing my files.

That made the setup start feeling less like a collection of individual programs and more like an actual working environment.

GitHub CLI: GitHub from the terminal

The last major tool I added was GitHub CLI.

Git and GitHub are related, but they solve different problems.

Git handles version control locally.

GitHub hosts repositories remotely and provides tools for collaboration.

GitHub CLI allows many GitHub operations to happen directly from the terminal.

After installing it, I verified the command:

gh --version

Then I authenticated using:

gh auth login

I selected:

GitHub.com
HTTPS
Login with a web browser

The CLI generated a temporary device code and completed the authentication through my browser.

But I ran into one more environment problem.

gh worked correctly inside normal PowerShell, but when I tried:

gh --version

inside VS Code, the terminal still returned:

gh : The term 'gh' is not recognized...

Closing and reopening the terminal did not solve it.

What eventually worked was closing VS Code completely, opening PowerShell where gh was already recognized, changing into my project directory, and launching VS Code from there:

code .

Once VS Code opened from that fresh PowerShell environment, its integrated terminal could also recognize GitHub CLI.

That was another reminder that applications can inherit environment information when they start.

If that environment changes while an application is already running, opening another terminal inside the same application may not always be enough.

Verifying the full toolchain

After fixing everything, I verified the complete setup from my terminal:

git --version
az version
docker --version
terraform -version
code --version
gh --version

At this stage, all six tools were available and working.

The versions themselves are not the important part because they will change as new releases come out.

What matters is that each command successfully returns a result before I depend on that tool later in a DevOps workflow.

Turning the setup into a real Git project

I didn't want to finish the exercise with nothing except installed applications.

I wanted the work documented and stored on GitHub.

I created a project directory:

mkdir devops-workstation
cd devops-workstation

Then initialized Git:

git init

I created a README.md documenting the tools, their versions, the commands I used to verify them, and what I learned during the setup.

After that, I staged the file:

git add README.md

and committed it:

git commit -m "docs: add workstation setup verification"

Publishing the project to GitHub

With the local repository ready, I created a public GitHub repository directly from the terminal:

gh repo create devops-workstation --public

Then I connected the local repository to GitHub:

git remote add origin https://github.com/<YOUR_USERNAME>/devops-workstation.git

I renamed the branch to main:

git branch -M main

and pushed the project:

git push -u origin main

After the push, I checked the repository status:

git status

and got:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

At that point, the setup was no longer something that existed only on my laptop.

It had become a small documented project that I could keep on GitHub and build on later.

Check out the repository

You can find the completed DevOps workstation setup and README on GitHub:

View the devops-workstation repository on GitHub

The problems that taught me the most

Looking back, the most useful parts of this setup were actually the moments when something didn't work.

I ran into four main problems.

Docker was installed but the engine wasn't running

The Docker CLI worked, but containers couldn't run until Docker Desktop had properly started the engine.

Azure CLI installed successfully but PowerShell couldn't see it

A new PowerShell session was needed before the az command became available.

Terraform only worked inside its own folder

The application itself was fine. The missing step was adding its directory to PATH.

GitHub CLI worked in PowerShell but not immediately in VS Code

VS Code was still running with an older environment, so I had to launch a fresh instance after the new CLI was available.

None of these were huge errors.

But fixing them forced me to understand what was actually happening underneath the commands instead of just copying installation instructions until something worked.

What I took away from the setup

Before doing this, I mostly thought about installing developer tools like this:

Download → Install → Done

Now I think about it more like this:

Install
   ↓
Make the command available
   ↓
Verify it
   ↓
Test the actual functionality
   ↓
Document the setup

That distinction matters.

Docker being installed is not the same as Docker being able to run containers.

Terraform existing somewhere on my laptop is not the same as being able to call terraform from my terminal.

Azure CLI being installed is not useful if my working environment cannot find az.

And a local Git repository becomes much more useful once it is documented and pushed somewhere I can actually share it.

This setup gave me a much clearer picture of how the different tools in a DevOps toolchain begin to connect.

What's next?

The next step is to start using these tools together for more practical work: containerizing applications, managing infrastructure through code, deploying resources to Azure, and eventually working with CI/CD pipelines.

Setting up the toolchain may not be the most exciting part of DevOps.

But before building anything serious, it helps to know that the tools underneath your workflow actually work.

Check this Article out and drop your thoughts on it

Anderson Chinedum — Sat, 03 Oct 2026 13:38:06 +0000

Anderson Chinedum

Oct 2

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

#firebase #react #webdev #authentication

10 min read

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

Anderson Chinedum — Fri, 02 Oct 2026 09:22:27 +0000

Authentication looked straightforward when all I needed was a way for users to sign in.

It became more interesting while I was building Loomwing, a custom-fashion marketplace application with two distinct user types: customers and tailors.

A customer needs a customer experience. A tailor needs a tailor experience. But I did not want returning users to choose their role every time they signed in.

That raised a more useful architectural question:

Once Firebase knows who a user is, how should the application determine what kind of user they are?

The solution I settled on was to separate identity from application-specific profile data.

Firebase Authentication handles identity.

Cloud Firestore stores the Loomwing profile, including the user's role.

The application then uses that persisted role to decide which experience to load.

The architecture

At a high level, I separated authentication from application-specific user data.

Firebase Authentication is responsible for identifying the user. Once a user signs in, Firebase gives the application a unique user ID — the UID.

Loomwing then uses that UID to look for a corresponding profile in Cloud Firestore:

users/{uid}

That Firestore document contains the information Loomwing needs beyond basic authentication, including the user's display name, authentication provider, and most importantly, their application role.

For now, a Loomwing user can have one of two roles:

customer
tailor

This separation means the login screen does not have to decide what kind of user someone is every time they return. Once a role has been selected during account creation, the persisted Firestore profile becomes the source of truth for the application's role-based experience.

In simple terms:

Firebase Authentication tells Loomwing who the user is. Firestore tells Loomwing what kind of user they are.

Initializing Firebase

The first thing I wanted was one place where Firebase would be initialized and reused across the app.

I didn't want authentication logic scattered across different React components, so I created a small Firebase module that exports both Authentication and Firestore.

import { getApp, getApps, initializeApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';
import { getFirestore } from 'firebase/firestore';

const requiredConfig = {
  apiKey: import.meta.env.VITE_FIREBASE_API_KEY,
  authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN,
  projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID,
  storageBucket: import.meta.env.VITE_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID,
  appId: import.meta.env.VITE_FIREBASE_APP_ID
};

export const firebaseApp =
  getApps().length > 0 ? getApp() : initializeApp(requiredConfig);

export const auth = getAuth(firebaseApp);
export const db = getFirestore(firebaseApp);

The getApps() check is there to make sure Firebase doesn't initialize the default app more than once.

My configuration values come from Vite environment variables instead of being written directly into the module.

For example:

VITE_FIREBASE_API_KEY
VITE_FIREBASE_AUTH_DOMAIN
VITE_FIREBASE_PROJECT_ID
VITE_FIREBASE_STORAGE_BUCKET
VITE_FIREBASE_MESSAGING_SENDER_ID
VITE_FIREBASE_APP_ID

One thing I had to understand here is that VITE_* variables are still exposed to the client bundle. They're useful for keeping configuration organized between environments, but they aren't a place for server-side secrets.

I also keep my actual .env.local file out of Git and use an .env.example file to document the variables the project expects.

Creating an account and saving the role

When somebody creates a Loomwing account, I need more than their email and password.

I also need to know how they intend to use the platform.

Right now, Loomwing has two roles:

customer
tailor

So during signup, the user chooses their role once.

The Firebase account is created first:

const credential =
  await createUserWithEmailAndPassword(auth, email, password);

firebaseUser = credential.user;

await updateProfile(firebaseUser, {
  displayName: fullName
});

await writeProfile(
  firebaseUser,
  fullName,
  role,
  'password'
);

After that, Loomwing creates the application profile in Firestore:

await setDoc(doc(db, 'users', user.uid), {
  uid: user.uid,
  email: user.email ?? '',
  displayName,
  role,
  authProvider,
  createdAt: serverTimestamp(),
  updatedAt: serverTimestamp()
});

The profile lives at:

users/{uid}

That means the Firebase Authentication account and the Loomwing profile are connected by the same UID.

I liked this approach because Firebase handles the identity side, while Firestore holds information that belongs specifically to Loomwing.

The role is one of those pieces of application-specific information.

It is stored in Firestore, not as a Firebase custom claim.

Signing in without asking for a role again

This was one of the first things I wanted to clean up from the earlier version of Loomwing.

During development, it can be tempting to have buttons like:

Sign in as Customer
Sign in as Tailor

That makes testing easy, but I didn't want that to become part of the real authentication system.

Once an account already exists, the user shouldn't have to keep telling Loomwing what role they belong to.

Email/password sign-in uses Firebase normally:

const credential =
  await signInWithEmailAndPassword(auth, email, password);

After Firebase authenticates the account, Loomwing reads the profile using the user's UID:

const snapshot = await getDoc(
  doc(db, 'users', user.uid)
);

The flow becomes:

Email + Password
       ↓
Firebase Authentication
       ↓
Firebase UID
       ↓
users/{uid}
       ↓
Saved role
       ↓
Customer or Tailor experience

The important part is this:

The sign-in form doesn't decide the user's role. The stored profile does.

That felt much cleaner than making role selection part of every login.

Google Sign-In was a little more complicated

Email/password signup already gives me a chance to ask whether someone is joining as a customer or tailor.

Google Sign-In doesn't.

Firebase can authenticate the Google account, but it still doesn't know what that person is supposed to be inside Loomwing.

The authentication itself is straightforward:

const credential =
  await signInWithPopup(
    auth,
    new GoogleAuthProvider()
  );

return await resolveFirebaseUser(
  credential.user
);

The interesting part happens afterwards.

Loomwing checks whether the authenticated Firebase user already has a profile at:

users/{uid}

If the profile exists, I load it and continue.

If it doesn't exist, the user is asked to choose a role before the Loomwing profile is created.

The flow looks like this:

Continue with Google
        ↓
Firebase authenticates user
        ↓
Does users/{uid} exist?
       /        \
     Yes         No
      ↓           ↓
Load profile   Ask for role
                  ↓
             Create profile
                  ↓
               Continue

I initially thought of this as a "new Google user" problem, but that's not quite accurate.

What really matters is whether the Loomwing profile exists.

The implementation doesn't depend on Google's isNewUser metadata. It checks Firestore.

That also covers cases where a Firebase account exists but the Loomwing profile is missing.

If the user closes the onboarding flow without finishing it, Loomwing signs them back out instead of leaving the app stuck in a half-finished authentication state.

Firebase identity alone wasn't enough

This is probably the part of the implementation that changed how I think about authentication the most.

At first, it's easy to think:

Firebase says the user is signed in, so the application session is ready.

For Loomwing, that isn't always true.

The application needs both:

Firebase authenticated user
        +
valid Firestore users/{uid} profile
        =
Loomwing application user

When Loomwing reads the Firestore document, it doesn't just accept whatever data happens to be there.

The profile is validated.

The role must be either:

customer

or:

tailor

The authentication provider must also be either:

password

or:

google

The saved profile is then converted into the user object Loomwing actually works with:

const toApplicationUser = (
  user: FirebaseUser,
  profile: LoomwingUserProfile
): User => ({
  id: profile.uid,
  name: profile.displayName,
  email: profile.email,
  role: profile.role,
  avatarUrl: user.photoURL ?? undefined,
  createdAt: profile.createdAt.toDate().toISOString()
});

The line that matters most here is:

role: profile.role

That persisted role becomes part of the real application session.

Restoring the session after refresh

The next thing I had to handle was refreshes.

Signing in successfully isn't very useful if refreshing the browser suddenly makes the application behave like the user is logged out.

Firebase gives us onAuthStateChanged() for this.

Loomwing subscribes to it when the app starts:

const unsubscribe = onAuthStateChanged(
  auth,
  async (firebaseUser) => {
    const currentRevision = ++revision;

    if (!firebaseUser) {
      if (!disposed) {
        listener({ status: 'signed-out' });
      }

      return;
    }

    const resolution =
      await resolveFirebaseUser(firebaseUser);

    if (
      !disposed &&
      currentRevision === revision
    ) {
      listener(resolution);
    }
  }
);

So when Loomwing loads, the process is roughly:

Application starts
       ↓
Wait for Firebase
       ↓
Auth state resolves
       ↓
Authenticated?
    /       \
   No        Yes
   ↓          ↓
Landing    Read profile
              ↓
         Restore session

The app stays in a loading state until Firebase has resolved that initial authentication state.

There is also a small detail in this implementation that I think is worth mentioning.

Reading the Firestore profile is asynchronous.

That means an older profile request could theoretically finish after a newer authentication event.

The revision value prevents that old result from replacing the newer state.

It's a small piece of code, but it's the kind of thing I probably wouldn't have thought much about when I was only building basic login screens.

Firestore rules are part of the auth system too

Getting somebody signed in is only one part of the job.

I also had to think about what that authenticated user should actually be allowed to read or change.

For the users collection, Loomwing first checks that the signed-in Firebase user owns the document being accessed:

function isSignedInAs(uid) {
  return request.auth != null
    && request.auth.uid == uid;
}

The profile rules then use that check:

match /users/{uid} {
  allow read: if isSignedInAs(uid);

  allow create: if isSignedInAs(uid)
    && hasValidProfileFields(uid)
    && request.resource.data.createdAt == request.time
    && request.resource.data.updatedAt == request.time;

  allow update: if isSignedInAs(uid)
    && hasValidProfileFields(uid)
    && request.resource.data.diff(resource.data).affectedKeys()
      .hasOnly(['email', 'displayName', 'updatedAt'])
    && request.resource.data.updatedAt == request.time;

  allow delete: if false;
}

A normal profile update can change:

email
displayName
updatedAt

But it can't change:

uid
role
authProvider
createdAt

That means somebody can't use a normal client-side profile update to turn:

role: "customer"

into:

role: "tailor"

I didn't want the role to be nothing more than a frontend setting.

Once the role affects what somebody can do inside the application, it also has to be treated as part of the application's security model.

Authentication doesn't mean onboarding is finished

I ran into another interesting case when I started testing real Tailor accounts.

A user could be:

Authenticated: yes
Role: tailor
Tailor profile: missing

Those aren't the same thing.

Earlier versions of the app had mock tailor data available, but I didn't want a real authenticated Tailor to suddenly inherit some placeholder profile just because a real profile hadn't been created yet.

So Loomwing looks for a TailorProfile that actually belongs to the authenticated user.

If it doesn't find one, the result stays null.

Instead of showing fake information, the application shows:

Set up your tailor profile

Opportunities, proposals, and orders stay unavailable until that real profile exists.

The actual profile editor is still a later product step.

And I'm okay with that.

I'd rather the app clearly show that something isn't finished than quietly attach placeholder information to a real account.

This also helped me separate three ideas that I used to think of as one thing:

Authentication

Who is this person?

Application role

Are they a customer or tailor?

Onboarding

Do they have all the information needed to use the features for that role?

A user can successfully complete authentication and still have onboarding work left to do.

Deploying it with Firebase Hosting

Getting everything working locally was one thing.

Getting it working after deployment exposed a couple of configuration mistakes.

The first one was the Hosting directory.

Loomwing uses Vite, so the production build goes into:

dist

Firebase Hosting therefore needs to serve that folder:

{
  "hosting": {
    "public": "dist",
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

The rewrite sends application routes back through index.html, which is what I need for the single-page application.

I also ran into an issue when deploying my Firestore rules.

At first, Hosting existed in firebase.json, but Firestore wasn't configured there.

So Firebase had no Firestore deployment target.

The configuration needed this as well:

{
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  }
}

Once that was in place, I could build:

npm run build

and deploy Hosting and Firestore rules together:

firebase deploy --only "hosting,firestore:rules"

Neither mistake was especially complicated once I understood what was wrong.

But they reminded me that getting a feature working on localhost is only part of finishing it.

Deployment is part of the system too.

What I learned

When I started working on this, I mostly thought of authentication as the part where somebody enters an email and password and gets access to the app.

After building this version of Loomwing, I don't really see it that way anymore.

The login form is probably the easiest part.

The more important questions were:

Who is this person?
What kind of Loomwing user are they?
What information do I trust?
What should they be allowed to change?
What happens when they're authenticated but their profile isn't complete?
What happens when they refresh the page?

The mental model I ended up with is:

Firebase Authentication
"Who are you?"

Firestore profile
"What kind of Loomwing user are you?"

Application logic
"What should you be able to do?"

Separating those responsibilities made the whole system easier for me to reason about.

It also gives me a cleaner foundation for the next parts of Loomwing, especially proper TailorProfiles, requests, proposals, measurements, orders, and the other role-specific workflows that will sit on top of this authentication layer.

There's still a lot I want to improve, but this version is a long way from the mock authentication flow I started with.

And more importantly, I understand why it's structured this way now.

If you're building a multi-role application with Firebase, I'd be interested to know how you've handled the separation between authentication, roles, and onboarding.