DEV Community: Adesoji1

How I Run Two Claude Code Accounts Side by Side in VS Code on Ubuntu Without Losing My History

Adesoji1 — Sat, 05 Sep 2026 17:31:35 +0000

I wanted a very specific setup on my Ubuntu machine: two different Claude accounts, both usable from the Claude Code VS Code extension, without repeatedly logging one account out to use the other.

I also wanted to keep the local Claude Code history and memory I had already built up, and I did not want the second account to interfere with my normal VS Code profile.

The setup that worked for me is simple once the pieces are separated properly:

Normal VS Code
    |
    v
~/.claude
    |
    v
Claude Account 1

VS Code launched with code-claude2
    |
    v
~/.claude-account2
    |
    v
Claude Account 2

The important idea is that Claude Code already supports a custom configuration directory through CLAUDE_CONFIG_DIR. Anthropic documents this variable as an override for the default ~/.claude directory and specifically notes that it is useful for running multiple accounts side by side.

VS Code also supports --user-data-dir, which lets you run isolated VS Code instances with separate settings, environment variables, extensions, and UI state.

Putting those two features together gives each Claude account its own home without requiring two Linux users or two separate installations of VS Code.

Important: This is the setup I used on Ubuntu with Bash and the Claude Code VS Code extension. Replace /home/your-user with your actual absolute home path.

The problem this solves

The obvious way to use two Claude accounts is to keep logging out and logging back in.

I did not want that.

Logging in and out of the same Claude profile means both identities are sharing the same configuration location. That creates unnecessary risk around credentials, session state, local history, and memory.

I wanted this instead:

ACCOUNT 1                         ACCOUNT 2
---------                         ---------
Own Claude login                  Own Claude login
Own Claude config                 Own Claude config
Own VS Code state                 Own VS Code state
Existing history                  Copied starting history
Existing memory                   Copied starting memory
No logout required                No logout required

I also wanted both accounts to be able to open the same Git repository.

That means the source code remains in one place. Only Claude's account state and the second VS Code profile are isolated.

A GitHub issue you should know about before setting this up

There is an open Claude Code issue, anthropics/claude-code #78988, about CLAUDE_CONFIG_DIR values that contain a literal ~.

The reported problem is easy to miss.

If Claude Code receives something like this literally:

CLAUDE_CONFIG_DIR=~/.claude-account2

through a path where the shell does not expand ~, Claude Code can interpret it as a relative path. The issue report shows Claude creating a directory literally named ~ inside the current project and writing configuration data there.

That can include session transcripts, history, backups, and other Claude data.

The issue was still open when I checked it on 5 September 2026.

The fix I used

I never pass a tilde to CLAUDE_CONFIG_DIR.

I use the full absolute path:

CLAUDE_CONFIG_DIR=/home/your-user/.claude-account2

and in VS Code:

{
  "name": "CLAUDE_CONFIG_DIR",
  "value": "/home/your-user/.claude-account2"
}

Not this:

{
  "name": "CLAUDE_CONFIG_DIR",
  "value": "~/.claude-account2"
}

This is one of the most important details in the whole setup.

You can find your real home directory with:

echo "$HOME"

If it prints:

/home/your-user

use that absolute path everywhere in the Account 2 configuration.

Part 1: Preserve the existing Claude Code data

1. Close active Claude Code sessions

I first stopped active Claude sessions and closed VS Code before copying anything.

For the CLI:

/exit

Then I checked for active processes:

pgrep -af claude
pgrep -af code

I did not start killing processes blindly. The goal was simply to avoid copying files while Claude was actively writing to them.

2. Back up the original Claude profile

My original Claude profile stays in the default location:

/home/your-user/.claude

Before touching it, I made a timestamped backup:

STAMP=$(date +%Y%m%d-%H%M%S)

cp -a "$HOME/.claude" \
      "$HOME/.claude-backup-$STAMP"

echo "Backup created at: $HOME/.claude-backup-$STAMP"

Then:

ls -ld "$HOME"/.claude*

I kept the original .claude directory exactly where it was. Account 1 would continue using it.

3. Create a second Claude configuration directory

mkdir -p /home/your-user/.claude-account2
chmod 700 /home/your-user/.claude-account2

At this point the structure is:

/home/your-user/
|
|-- .claude
|     `-- Account 1
|
`-- .claude-account2
      `-- Account 2

Part 2: Copy history and memory without copying Account 1's login

Claude Code stores local conversation transcripts under:

~/.claude/projects/<project>/<session-id>.jsonl

Auto memory is stored per project under:

~/.claude/projects/<project>/memory/

Anthropic's documentation describes those session transcripts as local JSONL files and auto memory as machine-local project memory.

That was useful for me because I wanted Account 2 to start with a copy of the local context I had already built.

4. Copy the useful data

The critical rule is this:

Do not copy Account 1's authentication credentials into Account 2.

I used rsync and excluded credentials and disposable runtime state.

A clean version of the copy command is:

rsync -a \
  --exclude='.credentials.json' \
  --exclude='backups/' \
  --exclude='ide/' \
  --exclude='sessions/' \
  --exclude='session-env/' \
  --exclude='shell-snapshots/' \
  --exclude='debug/' \
  --exclude='remote-settings.json' \
  --exclude='policy-limits.json' \
  /home/your-user/.claude/ \
  /home/your-user/.claude-account2/

Why exclude backups/?

During my first pass I copied the backup directory. Claude then found an old .claude.json backup from Account 1 and suggested restoring it into Account 2. I did not want Account 1's application or OAuth state becoming the starting state for Account 2.

Excluding the backup directory avoids that confusion.

5. Verify that history and memory actually copied

Compare the sizes:

du -sh /home/your-user/.claude/projects
du -sh /home/your-user/.claude-account2/projects

In my case the directories were roughly the same size, which was a good sign.

I also checked the file counts:

find /home/your-user/.claude/projects -type f | wc -l
find /home/your-user/.claude-account2/projects -type f | wc -l

And checked for memory directories:

find /home/your-user/.claude-account2/projects \
  -type d -name memory | head

The two copies do not need to be byte-for-byte identical, especially if runtime files were excluded.

6. Make sure Account 2 has no credentials yet

Before logging Account 2 in:

test -f /home/your-user/.claude-account2/.credentials.json \
  && echo "STOP: credentials already exist" \
  || echo "GOOD: Account 2 has no credentials yet"

The result I wanted was:

GOOD: Account 2 has no credentials yet

Never print the contents of .credentials.json to the terminal or paste it into a chat.

Part 3: Give Account 2 a clean Claude state and log it in

On my installation, Claude expected an Account 2 state file at:

/home/your-user/.claude-account2/.claude.json

I initialized it cleanly:

printf '{}\n' > /home/your-user/.claude-account2/.claude.json
chmod 600 /home/your-user/.claude-account2/.claude.json

Then I launched Claude using the alternate config directory:

CLAUDE_CONFIG_DIR=/home/your-user/.claude-account2 \
claude

I completed the first-run theme screen and signed in with the second Claude account.

After login, I checked:

/status

and, where available:

/usage

Then I exited:

/exit

Finally:

ls -l /home/your-user/.claude-account2/.credentials.json

At that point the account separation was real:

ACCOUNT 1
/home/your-user/.claude
    |
    |-- .credentials.json
    `-- projects/

ACCOUNT 2
/home/your-user/.claude-account2
    |
    |-- .credentials.json
    |-- .claude.json
    `-- projects/

Part 4: Make the VS Code extension use Account 2

This was the part that mattered most to me because I use the Claude Code VS Code extension much more than the CLI.

VS Code can launch a completely separate user-data environment with --user-data-dir.

That means the second VS Code instance can have its own:

Settings
Extensions
UI state
Environment
Claude extension state

without touching normal VS Code.

7. Create a separate VS Code user-data directory

mkdir -p /home/your-user/.config/Code-Claude-Account2/User

My two VS Code states now look like:

Normal VS Code:
~/.config/Code

Account 2 VS Code:
~/.config/Code-Claude-Account2

8. Configure the Claude extension in Account 2

The Account 2 VS Code settings file is:

/home/your-user/.config/Code-Claude-Account2/User/settings.json

I use:

{
  "claudeCode.environmentVariables": [
    {
      "name": "CLAUDE_CONFIG_DIR",
      "value": "/home/your-user/.claude-account2"
    }
  ],
  "claudeCode.preferredLocation": "panel",
  "window.title": "CLAUDE ACCOUNT 2 | ${activeEditorShort}${separator}${rootName}"
}

The custom window title is optional, but I like it because it makes it difficult to forget which VS Code window I am using.

Notice the absolute path again:

/home/your-user/.claude-account2

No ~.

Anthropic documents claudeCode.environmentVariables as a supported extension setting for environment variables passed to the Claude process.

Part 5: Create a dedicated `code-claude2` launcher

I created:

/home/your-user/.local/bin/code-claude2

with:

#!/usr/bin/env bash
set -e

export CLAUDE_CONFIG_DIR="/home/your-user/.claude-account2"

CODE_BIN="$(command -v code)"

if [ -z "$CODE_BIN" ]; then
    echo "Error: VS Code 'code' command not found in PATH."
    exit 1
fi

exec "$CODE_BIN" \
    --user-data-dir="/home/your-user/.config/Code-Claude-Account2" \
    --new-window \
    "$@"

Then:

chmod 700 /home/your-user/.local/bin/code-claude2

and:

which code-claude2

The result should point to the new launcher.

Why set CLAUDE_CONFIG_DIR in both the launcher and the extension settings?

I wanted the separation to be obvious at both levels:

code-claude2
    |
    |-- VS Code process gets CLAUDE_CONFIG_DIR
    |
    `-- Claude extension gets CLAUDE_CONFIG_DIR

Part 6: Keep Settings Sync off in Account 2

This deserves its own section.

I do not want Account 2's special VS Code settings syncing back into my normal VS Code environment.

In the Account 2 VS Code window:

Ctrl+Shift+P

Search for:

Settings Sync

If VS Code shows:

Settings Sync: Turn Off

I run it.

If it offers:

Turn On Settings Sync

or:

Backup and Sync Settings

then Sync is already off.

VS Code's documentation confirms that Settings Sync is something you explicitly turn on and that the Settings Sync: Turn off command disables it.

GitHub login is still fine

I can sign the second VS Code profile into the same GitHub account I normally use.

GitHub authentication and VS Code Settings Sync are separate concerns.

I use GitHub authentication for:

Clone
Pull
Push
Fetch
GitHub extensions
Repository access

but I leave Settings Sync off in the Account 2 VS Code profile.

When VS Code offers to enable Backup and Sync Settings, I decline it.

Optional extra protection

Check whether your VS Code build supports a --sync argument:

code --help | grep -A2 -B2 -- '--sync'

If your build explicitly shows support for --sync off, you can add it to the Account 2 launcher:

exec "$CODE_BIN" \
    --user-data-dir="/home/your-user/.config/Code-Claude-Account2" \
    --sync off \
    --new-window \
    "$@"

I would only add this after checking code --help on the machine. The important baseline is still the isolated --user-data-dir and keeping Settings Sync turned off in that profile.

Part 7: Verify the second VS Code before trusting it

Launch a project:

cd /home/your-user/projects/my-app
code-claude2 .

In the integrated terminal:

echo "$CLAUDE_CONFIG_DIR"

It should print exactly:

/home/your-user/.claude-account2

Then:

claude auth status

Open the Claude Code panel and run:

/status

or:

/usage

That should show Account 2.

I also checked:

/memory

and Session History to confirm the copied local context was available.

Will Account 2 see my old Claude Code sessions?

It can see the local history that was copied into its own projects/ directory, provided the project path matches.

Claude Code stores sessions using the project or working directory. If an old session was created from:

/home/your-user/projects/my-app

open that same project path when checking Session History.

Opening a duplicate of the repository from another path can make Claude treat it as a different project.

Also remember that the initial copy is a snapshot.

After the split:

Account 1 memory                  Account 2 memory
       |                                 |
       v                                 v
changes independently              changes independently
       |                                 |
       +----------- no automatic --------+
                    sync

I do not continuously rsync the two Claude directories back and forth. That could overwrite newer sessions, state, or credentials.

Project-level files such as CLAUDE.md that live inside the repository are naturally shared because both VS Code instances are opening the same source tree.

If I click the normal VS Code icon, which Claude account opens?

This is one of the questions I wanted answered clearly before relying on the setup.

My normal VS Code icon still launches the default VS Code environment.

Assuming I have not globally exported CLAUDE_CONFIG_DIR in .bashrc, normal VS Code uses Claude's default config:

Normal VS Code icon
       |
       v
~/.config/Code
       |
       v
No custom CLAUDE_CONFIG_DIR
       |
       v
~/.claude
       |
       v
Claude Account 1

That means clicking my ordinary VS Code icon opens the setup for Account 1.

I can verify this in normal VS Code with:

echo "$CLAUDE_CONFIG_DIR"

It should normally print nothing.

Claude then falls back to:

~/.claude

which is Account 1.

A useful rule is:

Do not export the Account 2 CLAUDE_CONFIG_DIR globally in .bashrc.

The Account 2 override belongs in the Account 2 launcher and Account 2 VS Code settings only.

How I choose which Claude account opens a project

This is the part that makes the whole setup easy to live with.

Open a project with Account 1

From inside the project:

cd /home/your-user/projects/my-app
code .

Or directly:

code /home/your-user/projects/my-app

Flow:

code .
  |
  v
Normal VS Code
  |
  v
Claude Account 1

Open the same project with Account 2

From inside the project:

cd /home/your-user/projects/my-app
code-claude2 .

Or directly:

code-claude2 /home/your-user/projects/my-app

Flow:

code-claude2 .
      |
      v
Isolated VS Code
      |
      v
/home/your-user/.config/Code-Claude-Account2
      |
      v
CLAUDE_CONFIG_DIR=/home/your-user/.claude-account2
      |
      v
Claude Account 2

Both VS Code instances can open the same Git repository.

I just avoid asking both Claude sessions to edit the same file at the same moment.

One thing to be careful about when opening folders graphically

This is easy to forget.

If I double-click a folder or file in Ubuntu and choose Open with Visual Studio Code, Ubuntu normally launches the standard VS Code application.

In my setup that means:

Graphical "Open with Visual Studio Code"
                 |
                 v
          Normal VS Code
                 |
                 v
          Claude Account 1

It does not automatically know that I wanted Account 2.

For Account 2, I either use:

code-claude2 /path/to/project

or create a separate Ubuntu desktop launcher called something like:

VS Code - Claude Account 2

A desktop file can look like this:

[Desktop Entry]
Name=VS Code - Claude Account 2
Comment=Visual Studio Code using Claude Account 2
Exec=/home/your-user/.local/bin/code-claude2 %F
Icon=visual-studio-code
Terminal=false
Type=Application
Categories=Development;IDE;
StartupNotify=true

Save it as:

~/.local/share/applications/vscode-claude-account2.desktop

Then:

chmod +x ~/.local/share/applications/vscode-claude-account2.desktop

That gives me two obvious graphical entry points:

Visual Studio Code
VS Code - Claude Account 2

What about GitHub in the second VS Code?

I use the same GitHub account in both VS Code environments.

In Account 2 I can sign into GitHub from Source Control or when VS Code needs authentication for a pull or push.

The key distinction is:

GitHub sign-in                 OK
Settings Sync                  Keep OFF
Claude Account 2 path          Keep isolated

Signing into GitHub does not mean I have to turn on Settings Sync.

A quick safety check for API environment variables

If an Anthropic API key is exported globally, it can change which authentication method Claude uses.

I check:

env | grep -E '^ANTHROPIC_(API_KEY|AUTH_TOKEN|BASE_URL)='

and:

grep -nH \
  'ANTHROPIC_API_KEY\|ANTHROPIC_AUTH_TOKEN\|ANTHROPIC_BASE_URL' \
  ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null

For a normal Claude subscription login, I do not want an unexpected API key overriding it.

Never paste an actual API key or .credentials.json contents into a blog, issue, chat, or screenshot.

The final workflow

This is what I ended up with:

                    UBUNTU
                      |
          +-----------+-----------+
          |                       |
          v                       v
   NORMAL VS CODE          ACCOUNT 2 VS CODE
      code .                code-claude2 .
          |                       |
          v                       v
 ~/.config/Code      ~/.config/Code-Claude-Account2
          |                       |
          v                       v
     ~/.claude             ~/.claude-account2
          |                       |
          v                       v
 Claude Account 1          Claude Account 2
          |                       |
          v                       v
 GitHub as normal          GitHub as normal
 Settings Sync as          Settings Sync OFF
 I normally prefer

And for any project:

Want Claude Account 1?
code /path/to/project

Want Claude Account 2?
code-claude2 /path/to/project

No logout.

No account swapping inside one Claude profile.

No second Linux user.

No duplicate source repository required.

Final checklist

Before I considered the setup finished, I checked all of these:

[ ] Account 1 still uses /home/your-user/.claude

[ ] Account 2 uses /home/your-user/.claude-account2

[ ] Account 1 and Account 2 each have their own .credentials.json

[ ] Account 2 started with copied project history and memory

[ ] CLAUDE_CONFIG_DIR always uses an absolute path

[ ] Account 2 VS Code uses its own --user-data-dir

[ ] echo "$CLAUDE_CONFIG_DIR" in Account 2 prints the Account 2 path

[ ] /status or /usage confirms the correct Claude account

[ ] Settings Sync remains OFF in Account 2

[ ] Normal VS Code still opens Account 1

[ ] code . opens Account 1

[ ] code-claude2 . opens Account 2

[ ] Graphical folder opening is treated as Account 1 unless I use the Account 2 launcher

For me, that is the cleanest way to run two Claude Code identities side by side on one Ubuntu workstation.

The main lesson is that the accounts themselves are not the difficult part. The important part is isolating the state around them: Claude's config directory, VS Code's user-data directory, and the environment variable that connects the two.

Once those are separate, switching accounts becomes nothing more than choosing the right launcher.

Sources and further reading

Anthropic, Claude Code environment variables

https://code.claude.com/docs/en/env-vars

Anthropic, Claude Code in VS Code

https://code.claude.com/docs/en/vs-code

Anthropic, Claude Code memory

https://code.claude.com/docs/en/memory

Anthropic, Claude Code sessions

https://code.claude.com/docs/en/sessions

Visual Studio Code command line documentation

https://code.visualstudio.com/docs/configure/command-line

Visual Studio Code Settings Sync documentation

https://code.visualstudio.com/docs/configure/settings-sync

Claude Code GitHub issue #78988

https://github.com/anthropics/claude-code/issues/78988

Choosing the Right Git Branching Strategy for Your Organization

Adesoji1 — Wed, 11 Oct 2023 11:24:18 +0000

Effective version control is at the heart of modern software development, and Git has become the industry standard for managing source code. Git offers a flexible branching model that allows teams to collaborate, track changes, and maintain code stability. However, to fully harness the power of Git, it's crucial to establish a clear and effective branching strategy tailored to your organization's needs. In this article, we'll explore the importance of choosing the right Git branching strategy and discuss several popular options.

The Significance of a Git Branching Strategy

A well-defined Git branching strategy streamlines the development process, enhances collaboration, and ensures code quality. It offers a framework for managing different aspects of your codebase, including feature development, bug fixes, and release management. Here are some key benefits:

Isolation of Features 🌱: Feature branches allow developers to work on new functionality in isolation, preventing conflicts with the main codebase.
Collaboration 🤝: A branching strategy facilitates collaboration by providing a structured approach to code contributions and reviews.
Release Management 🚀: It simplifies the process of preparing and deploying new releases, ensuring that only stable and tested code is pushed to production.
Code Stability 🛡️: It promotes code stability by separating experimental or in-progress work from the production-ready code.

Common Git Branching Strategies

There are several branching strategies to consider, depending on the specific needs of your organization. Let's explore a few of the most popular ones:

1. Feature Branch Workflow 🚀🌱

Overview: This strategy involves creating a new branch for each feature or issue. These branches are typically branched off from the main development branch.
Advantages: It keeps feature development isolated, making it easy to manage and test new functionality.
Considerations: Developers should regularly merge the latest changes from the main development branch into their feature branches to avoid integration issues.

2. Git Flow 🌊🚦

Overview: Git Flow defines a specific branching model with long-lived branches, including master, develop, feature/, release/, and hotfix/.
Advantages: It provides a clear structure for different types of development work, making it suitable for larger projects.
Considerations: The Git Flow model can be more complex and may require disciplined use of the various branch types.

3. GitHub Flow 🐙💬

Overview: GitHub Flow is a simplified workflow used in GitHub and similar platforms. Development occurs on feature branches, and changes are merged into the main branch (usually named main or master) via pull requests.
Advantages: It encourages a fast-paced, review-centric development process, well-suited for smaller teams and frequent deployments.
Considerations: GitHub Flow may require careful attention to automated testing and continuous integration.

4. Trunk-Based Development 🌲✏️

Overview: This strategy involves minimal branching, where developers commit directly to the main branch (e.g., main or master).
Advantages: It encourages frequent integration and can work well for smaller teams and projects.
Considerations: To maintain code stability, strong continuous integration practices and automated testing are essential.

5. Release Branching 🚀🌿

Overview: A new branch is created for each major release. Developers continue working on feature branches and merge changes into the release branch as needed.
Advantages: This strategy provides a clear structure for release management, ensuring that only stable features are included in a release.
Considerations: It may involve extra coordination and testing efforts as you approach a release.

6. GitOps Workflow 🛠️💻

Overview: Focused on managing infrastructure and configurations using Git, GitOps deploys and configures applications based on changes to Git repositories.
Advantages: It brings the benefits of version control to infrastructure and configurations, allowing for automated, auditable, and repeatable deployments.
Considerations: GitOps may require a shift in infrastructure management practices and tools.

Choosing the Right Strategy

The choice of a Git branching strategy should align with your organization's development workflow, release cycle, and project requirements. Here are some key considerations to help you decide:

Team Size: Smaller teams may benefit from simpler strategies like GitHub Flow or Trunk-Based Development, while larger teams may prefer Git Flow or Release Branching.
Release Frequency: If you have frequent releases, a strategy that emphasizes rapid integration, such as GitHub Flow or Trunk-Based Development, could be more suitable.
Testing and Automation: Consider your testing and continuous integration capabilities. Strategies like GitHub Flow and Trunk-Based Development rely heavily on automated testing.
Release Stability: If your organization values code stability in production releases, a strategy like Release Branching or Git Flow may be preferable.
Infrastructure Management: For organizations focusing on infrastructure and configuration management, GitOps may be the right choice.

Remember that the chosen strategy is not set in stone and can evolve as your organization's needs change. Regularly revisit and adjust your Git branching strategy to ensure it continues to support efficient and high-quality software development.

In conclusion, a well-defined Git branching strategy is a critical component of successful version control and software development. By selecting the strategy that best aligns with your organization's needs, you can streamline development, improve collaboration, and ensure the delivery of stable and reliable software. Whether you opt for a simple workflow like GitHub Flow or a more structured approach like Git Flow, the key is to adapt and optimize your strategy as your projects and teams evolve.

Set up a CI/CD pipeline using GitHub Actions to a GKE cluster

Adesoji1 — Tue, 31 Jan 2023 11:17:53 +0000

Setting up a CI/CD pipeline using GitHub Actions to a Google Kubernetes Engine (GKE) cluster

In this article, we'll show you how to set up a Continuous Integration/Continuous Deployment (CI/CD) pipeline using GitHub Actions to a GKE cluster. A CI/CD pipeline automates the deployment of code changes to a production environment. With this setup, code changes will be automatically deployed to the GKE cluster whenever code is pushed to the GitHub repository.

Step 1: Create a GitHub repository

Create a GitHub repository for your project and push the code to the repository. click here on how to create a github repository and proceed to step 2

Step 2: Create a GKE cluster

Create a GKE cluster using the Google Cloud Console or the gcloud CLI.

Replace <CLUSTER_NAME> and <ZONE> with the appropriate values for your project.

Step 3: Create a Kubernetes deployment

Create a file named deployment.yml or .yaml .Create a Kubernetes deployment that defines the desired state of your application. The deployment should specify the number of replicas, the container image to use, and any environment variables or secrets required.

Replace <DEPLOYMENT_NAME>, <REPLICAS>, <APP_LABEL>, <CONTAINER_NAME>, <IMAGE_NAME>, <ENV_VAR_NAME>, and <ENV_VAR_VALUE> with the appropriate values for your project

Step 4: Create a GitHub Actions Workflow

Create a GitHub Actions workflow to automate the deployment of the Kubernetes deployment to the GKE cluster. The workflow should perform the following steps:

Check out the code from the GitHub repository.
Build the container image.
Push the container image to a container registry, such as Google Container Registry (GCR).
Deploy the container image to the GKE cluster using kubectl.

A workflow is an automated procedure that can be configured to execute one or more jobs. Workflows are defined by a YAML file that is checked into your repository and run when triggered by an event there, manually, or according to a set schedule.

A repository can have multiple workflows, each of which can carry out a unique set of tasks. Workflows are defined in the .github/workflows directory in a repository. One workflow could be used to create and test pull requests, another to deploy your application each time a release is made, and yet another to add a label each time a new issue is opened.

Create a file named .github/workflows/deploy.yml with the following content:

Remeber that this .yml should be written on a single yaml file, i splitted the screenshot into two in order for the contents to be visible

Replace <PROJECT_ID>, <CLUSTER_NAME>, <ZONE>, <IMAGE_NAME>, and <VERSION> with the appropriate values for your project.

Step 5: Add Secrets

In the workflow, the GCLOUD_AUTH secret is used to authenticate with the GKE cluster. Create the GCLOUD_AUTH secret in the GitHub repository and add the content of a service account key that has sufficient permissions to deploy to the GKE cluster.

To create the secret, navigate to the GitHub repository, go to the "Settings" tab, and click on "Secrets." Then, click on the "New repository secret" button and give the secret a name (e.g. "GCLOUD_AUTH") and paste in the content of the service account key.

Step 6: Push code changes to the GitHub repository

Push code changes to the GitHub repository and observe the GitHub Actions workflow being triggered. If the workflow is successful, the changes should be automatically deployed to the GKE cluster.

In conclusion, with the setup of a CI/CD pipeline using GitHub Actions, you can automate the deployment process and save time and effort in manual deployments. Additionally, the pipeline ensures that the latest code changes are deployed to the production environment, improving the overall quality of the application.

How to become a DevOps Professional in 2023?

Adesoji1 — Tue, 24 Jan 2023 15:44:45 +0000

Gain a strong understanding of the Principles and Practices of Software Development and IT Operations.
Build a foundation in key technologies such as Linux, Git, and cloud computing.

3 .Learn about containerization and orchestration tools such as kubernetes and docker

4 .Familiarize yourself with infrastructure-as-code tools such as Terraform and Ansible.

5 .Learn about monitoring and logging tools such as Prometheus and Elasticsearch.

6 .Get hands-on experience through internships like udacity,torre or personal projects hosted on Github, or contributing to open-source projects in cncf and Kodekloud.

7 .Consider earning certifications, such as AWS Certified DevOps Engineer or, Azure Devops or Google Cloud Professional DevOps Engineer.

8 .Continuously learn and stay up-to-date with the latest trends and technologies in the field.

9 .Network with other professionals in the industry, attend meetups, and participate in online communities.

10 .Look for job opportunities, apply, and build your career in this field.

Using Helm to deploy a Frontend and backend Application

Adesoji1 — Thu, 12 Jan 2023 17:47:49 +0000

Helm is a package manager for Kubernetes that makes it easy to manage and deploy applications to a cluster. Helm charts are a way to package and distribute applications and their dependencies, making it easy to deploy and manage those applications on a cluster. In this article, we will go over how to create a Helm chart that deploys two application containers: a frontend app and its backend into a Kubernetes cluster.

1.Creating a Helm Chart

To create a Helm chart, we will first need to install Helm on our local machine. Once Helm is installed, we can use the Helm CLI to create a new chart. To do this, we will use the following command:

helm create mychart

This will create a new chart called "mychart" in the current directory. The chart will contain several files and directories that make up the structure of the chart. The most important files are the "Chart.yaml" file, which contains metadata about the chart, and the "values.yaml" file, which contains the default values for the chart's variables.The chart.yaml file seen in the picture above was the yaml file used in the project and available at my github repository

2.Deploying Two Application Containers

Once the chart is created, we can start adding our application containers to it. To do this, we will create two new directories in the chart, one for the frontend app and one for the backend app. In each of these directories, we will create a new file called "deployment.yaml", which will contain the Kubernetes deployment configuration for the corresponding app.

In the deployment.yaml file, we will specify the image for the container, the number of replicas, and the ports that the container will expose. We will also specify any environment variables or volumes that the container requires. Once the deployment.yaml file is created for both the frontend and backend, we will add them to the chart's templates directory.

3.Configuring Ingress

Once the chart is configured to deploy our two application containers, we will need to configure Ingress to access our applications. Ingress is a Kubernetes resource that allows external traffic to reach our applications. To configure Ingress, we will create a new file in the chart's templates directory called "ingress.yaml". This file will contain the configuration for the Ingress resource. example of an ingress file is seen below.

In the ingress.yaml file, we will specify the hostname and path for the Ingress resource, as well as the service that it should route traffic to. We will also specify any annotations or rules that are needed for the Ingress resource to work correctly. Once the ingress.yaml file is created, we will add it to the chart's templates directory. A diagram that illustrates the architecture of this solution could be drawn using draw.io

Once the chart is configured and all the necessary files are added, we can use Helm to deploy it to our Kubernetes cluster. To do this, we will use the following command:

helm install mychart

This will deploy our two application containers and configure Ingress to access them. With this configuration, we can now access our frontend and backend application . This post just shares the concept behind using helm. The complete files are available at my github profile. kindly view my github and star my repository.

Adesoji1 / Deploy-Web-App-Using-Helm

Create a helm chart ,.Your helm chart should deploy two application containers: a frontend app and it’s backend into your Kubernetes cluster

Deploy-Web-App-Using-Helm

Create a helm chart ,.Your helm chart should deploy two application containers: a frontend app and it’s backend into your Kubernetes cluster

View on GitHub

Deploying BLOOM. A 176Billion Parameter Multi-Lingual Large Language Model.

Adesoji1 — Thu, 12 Jan 2023 17:13:50 +0000

BLOOM is a multi-lingual large language model that was recently introduced by Facebook AI. It is a transformer-based model that is trained on a massive amount of text data from multiple languages, resulting in a model with 176 billion parameters. This makes BLOOM one of the largest language models currently available, and it is capable of performing many natural language processing (NLP) tasks with high accuracy and efficiency.

Deploying BLOOM in a production environment can be a complex task, as it requires a significant amount of computational resources and memory. However, the benefits of using such a large language model can be significant, particularly in applications such as machine translation, text summarization, and question answering.

The first step in deploying BLOOM is to acquire the necessary resources. This includes a high-performance computing cluster with a large amount of memory and storage. Additionally, the model will require a large amount of data to fine-tune and evaluate. This can include text data from multiple languages, as well as annotated data for specific NLP tasks.

Once the resources are acquired, the next step is to prepare the data. This includes cleaning, preprocessing, and vectorizing the text data. The data should also be split into training, validation, and test sets for evaluation.

The next step is to fine-tune the model on the prepared data. This can be done using a library such as Hugging Face's Transformers, which provides a simple interface for fine-tuning and evaluating transformer-based models. The fine-tuning process can take several days, depending on the amount of data and the computational resources available.

Once the model is fine-tuned, it can be deployed in a production environment. This can be done by exporting the model and serving it using a framework such as TensorFlow Serving or Hugging Face's Model Hub. The model can then be used to perform NLP tasks such as machine translation, text summarization, and question answering.

Here is an example Python script that demonstrates how to fine-tune and deploy BLOOM using the Hugging Face's Transformers library:

from transformers import AutoModelForCausalLM, AutoTokenizer

# load the BLOOM model
model = AutoModelForCausalLM.from_pretrained("facebook/bloom-base-176b")
tokenizer = AutoTokenizer.from_pretrained("facebook/bloom-base-176b")

# fine-tune the model on your data
# code to fine-tune the model

# save the fine-tuned model
model.save_pretrained('./fine_tuned_model')
tokenizer.save_pretrained('./fine_tuned_model')

# load the fine-tuned model
model = AutoModelForCausalLM.from_pretrained('./fine_tuned_model')
tokenizer = AutoTokenizer.from_pretrained('./fine_tuned_model')

# use the model to perform NLP tasks
output = model.generate(tokenizer.encode("What is the meaning of life?"))
print(tokenizer.decode(output[0]))

In conclusion, This is how i could explain what it takes to deploy a multi-lingual large language model . Hope you enjoyed the article? kindly like my post

Text2Topic

Adesoji1 — Thu, 12 Jan 2023 16:59:17 +0000

Text to topic generation in NLP is a process that involves identifying the main topics or themes present in a given text. This process is typically performed using machine learning algorithms such as Latent Dirichlet Allocation (LDA) or Non-negative Matrix Factorization (NMF). These algorithms are able to identify patterns in the text data and extract the underlying topics.

Python is a popular programming language for implementing text to topic generation in NLP. One of the main reasons for this is the availability of powerful libraries such as Gensim, NLTK, and scikit-learn that make it easy to implement these algorithms. Additionally, Python is a versatile language that can be used for both data preprocessing and modeling.

To implement text to topic generation in NLP using Python, the following steps are typically followed:

Data preprocessing: This involves cleaning the text data, removing stop words, and tokenizing the text.
Vectorization: This involves converting the text data into a numerical format that can be used by the machine learning algorithm. This can be done using techniques such as bag of words or TF-IDF.
Model training: This involves training the machine learning algorithm on the vectorized text data. This can be done using libraries such as Gensim or scikit-learn.

4.Topic extraction: Once the model is trained, it can be used to extract the main topics present in the text data. This can be done by analyzing the model's output and identifying the most probable topics.

5.Evaluation: The topics extracted from the text data can be evaluated using various metrics such as perplexity or coherence score.

The results of text to topic generation can be used for a variety of tasks such as text classification, sentiment analysis, and information retrieval. It can also be used to identify patterns and trends in the text data, which can be useful for businesses and organizations to understand their customer behavior and preferences.

In summary, text to topic generation in NLP is a powerful technique that can be used to extract the main topics present in a given text. Python programming language is popular choice for implementing this technique due to the availability of powerful libraries and its versatility. It can be used for a variety of tasks such as text classification, sentiment analysis, and information retrieval and can also be used to identify patterns and trends in the text data.Here is a sample Python script below that demonstrates text to topic generation using the Gensim library:

# import the necessary libraries
from gensim import corpora, models
from nltk.corpus import stopwords
from nltk.tokenize import word_tokenize

# define the text data
text_data = ["This is some sample text about topic A",
             "This is some more text about topic B",
             "And this is some text about topic C"]

# preprocess the text data
stop_words = set(stopwords.words('english'))
texts = [[word for word in word_tokenize(document.lower()) if word not in stop_words] for document in text_data]

# create a dictionary from the text data
dictionary = corpora.Dictionary(texts)

# create a corpus from the text data
corpus = [dictionary.doc2bow(text) for text in texts]

# train the LDA model on the corpus
ldamodel = models.LdaModel(corpus, num_topics=3, id2word=dictionary)

# extract the topics from the model
topics = ldamodel.print_topics(num_topics=3, num_words=3)

# print the topics
for topic in topics:
    print(topic)

No-Code Transfer Learning from Rules & Models in the Annotation Lab

Adesoji1 — Thu, 12 Jan 2023 16:48:29 +0000

Transfer learning is a powerful technique in machine learning that allows a model to learn from one task and apply that knowledge to a different, but related, task. This technique has become increasingly popular in recent years, particularly in the field of natural language processing (NLP). NLP is the use of computers to process and analyze human language, making it a perfect fit for transfer learning.

One area where transfer learning has been particularly useful is in the annotation lab. Annotation is the process of adding information to a text or image, such as labels, comments, or tags. In the annotation lab, transfer learning can be used to improve the accuracy and efficiency of the annotation process.

One approach to transfer learning in the annotation lab is using no-code transfer learning from rules and models. This approach allows for the implementation of transfer learning without the need for coding or programming knowledge. This is particularly useful for non-technical users who want to implement transfer learning in their annotation lab.

The steps involved in implementing no-code transfer learning from rules and models in the annotation lab are as follows:

Collect a large corpus of text data: This will be used to train the model.
Annotate the text data: This will be used to fine-tune the model.
1. Use a natural language processing script: This script will be used to train the model on the text data.
2. Fine-tune the model: The model will be fine-tuned on the annotated text data.
3. Evaluate the model: The model will be evaluated on a test set to determine its accuracy.
4. Annotate text data: The model will be used to annotate text data.
5. Evaluate the annotation: The annotation will be evaluated to determine its accuracy.
6. Repeat steps 3-7 as needed: The model will be fine-tuned and evaluated until it reaches an acceptable level of accuracy.

In this approach, the natural language processing script plays a crucial role in the transfer learning process. This script is used to train the model on the text data, and it can be easily customized to fit the specific needs of the annotation lab. The script can also be used to fine-tune the model, making it more accurate and efficient.

The benefits of using no-code transfer learning from rules and models in the annotation lab are numerous. First, it allows for faster and more accurate annotation of text data. Additionally, it can be used to improve the performance of existing models. It also allows for non-technical users to implement transfer learning in their annotation lab, making it more accessible to a wider range of users.

Despite its benefits, no-code transfer learning from rules and models in the annotation lab does have some limitations. One of the biggest limitations is the lack of data. In order to train a model effectively, a large corpus of text data is required. Additionally, the data must be of high quality and well-annotated. Another limitation is the need for domain-specific knowledge. This is because the model needs to understand the context and meaning of the text in order to annotate it accurately.

In conclusion, no-code transfer learning from rules and models in the annotation lab is a powerful technique that can be used to improve the accuracy and efficiency of the annotation process. It allows for the implementation of transfer learning without the need for coding or programming knowledge, making it accessible to a wider range of users. The natural language processing script plays a crucial role in the transfer learning process, and it can be easily customized to fit the specific needs of the annotation lab. Despite its limitations, no-code transfer learning from rules

DEV Community: Adesoji1

How I Run Two Claude Code Accounts Side by Side in VS Code on Ubuntu Without Losing My History

The problem this solves

A GitHub issue you should know about before setting this up

The fix I used

Part 1: Preserve the existing Claude Code data

1. Close active Claude Code sessions

2. Back up the original Claude profile

3. Create a second Claude configuration directory

Part 2: Copy history and memory without copying Account 1's login

4. Copy the useful data

5. Verify that history and memory actually copied

6. Make sure Account 2 has no credentials yet

Part 3: Give Account 2 a clean Claude state and log it in

Part 4: Make the VS Code extension use Account 2

7. Create a separate VS Code user-data directory

8. Configure the Claude extension in Account 2

Part 5: Create a dedicated code-claude2 launcher

Part 6: Keep Settings Sync off in Account 2

GitHub login is still fine

Optional extra protection

Part 7: Verify the second VS Code before trusting it

Will Account 2 see my old Claude Code sessions?

If I click the normal VS Code icon, which Claude account opens?

How I choose which Claude account opens a project

Open a project with Account 1

Open the same project with Account 2

One thing to be careful about when opening folders graphically

What about GitHub in the second VS Code?

A quick safety check for API environment variables

The final workflow

Final checklist

Sources and further reading

Choosing the Right Git Branching Strategy for Your Organization

The Significance of a Git Branching Strategy

Common Git Branching Strategies

1. Feature Branch Workflow 🚀🌱

2. Git Flow 🌊🚦

3. GitHub Flow 🐙💬

4. Trunk-Based Development 🌲✏️

5. Release Branching 🚀🌿

6. GitOps Workflow 🛠️💻

Choosing the Right Strategy

Set up a CI/CD pipeline using GitHub Actions to a GKE cluster

How to become a DevOps Professional in 2023?

Using Helm to deploy a Frontend and backend Application

Adesoji1 / Deploy-Web-App-Using-Helm

Create a helm chart ,.Your helm chart should deploy two application containers: a frontend app and it’s backend into your Kubernetes cluster

Deploy-Web-App-Using-Helm

Deploying BLOOM. A 176Billion Parameter Multi-Lingual Large Language Model.

Text2Topic

No-Code Transfer Learning from Rules & Models in the Annotation Lab

Part 5: Create a dedicated `code-claude2` launcher