Tag: GitOps

7 things all devops practitioners need from Git

Git is a powerful tool for version control, enabling multiple developers to work together on the same codebase without stepping on each other’s toes. It’s a complex system with many features, and getting to grips with it can be daunting. Here are seven insights that I wish I had known when I started working with Git.

The Power of git log

The git log command is much more powerful than it first appears. It can show you the history of changes in a variety of formats, which can be extremely helpful for understanding the evolution of a project.

# Show the commit history in a single line per commit
git log --oneline

# Show the commit history with graph, date, and abbreviated commits
git log --graph --date=short --pretty=format:'%h - %s (%cd)'

Branching is Cheap

Branching in Git is incredibly lightweight, which means you should use branches liberally. Every new feature, bug fix, or experiment should have its own branch. This keeps changes organized and isolated from the main codebase until they’re ready to be merged.

# Create a new branch
git branch new-feature

# Switch to the new branch
git checkout new-feature

Or do both with:

# Create and switch to the new branch
git checkout -b new-feature

git stash is Your Friend

When you need to quickly switch context but don’t want to commit half-done work, git stash is incredibly useful. It allows you to save your current changes away and reapply them later.

# Stash your current changes
git stash

# List all stashes
git stash list

# Apply the last stashed changes and remove it from the stash list
git stash pop

git rebase for a Clean History

While merging is the standard way to bring a feature branch up to date with the main branch, rebasing can often result in a cleaner project history. It’s like saying, “I want my branch to look as if it was based on the latest state of the main branch.”

# Rebase your current branch on top of the main branch
git checkout feature-branch
git rebase main

Note: Rebasing rewrites history, which can be problematic for shared branches.

The .gitignore File

The .gitignore file is crucial for keeping your repository clean of unnecessary files. Any file patterns listed in .gitignore will be ignored by Git.

# Ignore all .log files
*.log

# Ignore a specific file
config.env

# Ignore everything in a directory
tmp/**

git diff Shows More Than Just Differences

git diff can be used in various scenarios, not just to show the differences between two commits. You can use it to see changes in the working directory, changes that are staged, and even differences between branches.

# Show changes in the working directory that are not yet staged
git diff

# Show changes that are staged but not yet committed
git diff --cached

# Show differences between two branches
git diff main..feature-branch

The Reflog Can Save You

The reflog is an advanced feature that records when the tips of branches and other references were updated in the local repository. It’s a lifesaver when you’ve done something wrong and need to go back to a previous state.

# Show the reflog
git reflog

# Reset to a specific entry in the reflog
git reset --hard HEAD@{1}

Remember: The reflog is a local log, so it only contains actions you’ve taken in your repository.

Understanding these seven aspects of Git can make your development workflow much more efficient and less error-prone. Git is a robust system with a steep learning curve, but with these tips in your arsenal, you’ll be better equipped to manage your projects effectively.

Knowledge spew on GitOps

In working with a handful of customers the concept of GitOps continues to resonate more and more. Let us dive into a brain dump of some of the conversations related to GitOps and how these customers tackled the task at hand.

First thing to remember is these customers are not massive. They are rather common actually. A Gartner defined “medium-sized” enterprise. Keep in mind these customers have the same issues as the giant enterprises just at a different scale.

In every case there was a user story. At a high level, a common theme was the need to roll out updates to a specific application regularly enough to find ways to entice the consumer to purchase a widget of some sort. Ok, A/B testing. Simple enough.

Each of the customers were in different maturity levels when it came to development processes, kubernetes knowledge, and devops methods. However they all have one thing in common…the need to deliver an application to their customer base on a deadline and continuously improve the application based on user feedback. All three of them were successful in meeting their self imposed deadlines. How?

Simple. Every one of them came together, ironed out a plan, and implemented the plan. The interesting part, every one of them already knew how to get the product to market. All they needed was a bit of guidance on how to overcome obstacles and get shit done. How?

  • Step one. Define the top of the mountain, the finish line, the end result.
  • Step two. The project leads built out a high level timeline from end to beginning.
  • Step three. All of the team members came together to build out the task teams.
  • Step four. Each of the teams built out their respective timeline for contribution.
  • Step five. Build.

Now how does this relate to GitOps? GitOps was the pivotal methodology to get it done. The pipeline was built with all of the parts in mind. If you recall the DevOps “infinity loop“, the key is to use that and combine it with the OODA loop decision model. The combination creates a very powerful decision making framework facilitating agile development with constant improvement. Sound simple? It’s not. It is in theory, but the implementation is like a relationship. Everything is great when dating, but the hard work is when dating turns to marriage. Same goes for creating a product. Designing the product, what it needs to do, all of the moving parts is fun. The real work comes in when the first working build is complete.

This is where GitOps shines. The developers build things, test locally, and commit. The pipelines move it through the process and all of the other teams contribute to each part in this machine. If one part breaks down, the other work stops to crowdsource the problem. The problem is fixed and the machine continues on. GitOps is the magical fairy dust. What about the technology?

The technology is rather mundane actually. Git. A code repository. A CI/CD pipeline. A build system. A test harness. A deployment platform. Git…the tools of choice are Github or Gitlab. Github is pretty slick, but Gitlab will allow for running locally in small environments building closed source deliverables. Each has a pipeline mechanism or there are many other tools such as Texton, Argo, CircleCI and many others with various features depending on what was needed. For build systems, many exist and again each as features as needed. However the deployment platform consistently remains the same, Kubernetes.

Building deploy-able applications at scale is hard. There are many other moving parts, processes, tools, etc. in play. However one thing stands out in all of these engagements…give the right people who have the will to succeed the skills needed to succeed and the execution part will look easy.

It is always fun to be a part of something, but its most precious reward is being able to step away and watch the machine run on it’s own.

That’s the end of this spew. It went everywhere…maybe it’s more like a sneeze.

Peace out.