This week’s issue brings you:

• Navigating Software Updates: A Closer Look at Deployment Strategies

• What Does an API Gateway Do? (Recap)

• SemVer Explained in Very Simple Terms (Recap)

• How the Most Prominent Git Branching Strategies Work (Recap)

READ TIME: 5 MINUTES

Navigating Software Updates: A Closer Look at Deployment Strategies

Nailing the right deployment strategy is key to smoothly introducing new features and updates.

Think of them as the secret sauce for reducing risks, avoiding interruptions, and delivering a seamless experience to users.

Among the many possible approaches, there are five that really shine for their effectiveness and adaptability.

Let’s take a look at their distinct traits and why developers worldwide rely on them for smooth software launches.

Blue/Green Deployment

This method is a game-changer for zero downtime updates. There are two environments involved: Blue and Green. One is always active, while the other stands by. When a new software version is ready for release, it's deployed to the currently inactive environment, either Blue or Green. After deployment, developers are given the opportunity to test the changes in a real-world scenario without disruption to live traffic.

Once everything is tested, all traffic is then directed to the new environment. This switch is swift, ensuring users don't notice a thing.

The downfall of Blue/Green Deployment is its complexity and cost. Managing two identical production environments can drain your resources, potentially doubling infrastructure costs.

Canary Deployment

Named after canary birds in mines, it involves rolling out changes to a small group first, keeping an eye on performance, and gathering feedback.

If the new feature does well with the initial group, it's gradually introduced to more users. If problems do pop up, disruption is kept to a minimum as it's isolated to a small set of users and developers have an opportunity to fix them or roll back the system before it’s seen by more users.

To ensure efficiency, the rollout should be kept within a reasonable timeframe, with adjustments to the size of user increments based on each phase's outcomes.

Rolling Deployment

Rolling deployment is about introducing new software in stages. Instead of updating all servers or delivering to all users at once, it starts small and expands.

This keeps most of the system up and running during the update, reducing the risk of a complete shutdown.

If you're working on a system where it's crucial to keep things continuously operational, this approach is your go-to. However, it does bump up the deployment time which can be problematic for large systems. Managing incremental updates across complex applications can also be challenging, and there’s a risk of temporary inconsistency in the system during the update process.

Feature Flags

Think of feature flags as on-off switches for new features. They allow teams to deploy features quietly, turning them on for specific users when it makes sense.

Feature flags let you test-drive new features with specific users before going public.

These flags also support strategies like canary releases and A/B testing. They provide real, comparative insights for future development, and the ability to quickly switch off a problematic feature cutting down the risks when rolling out updates.

Feature flags are a very useful and popular tool but having too many flags can become cumbersome, increasing the risk of conflicts between features. It’s a good idea to keep feature flags short-lived where possible.

A/B Testing

A/B testing in deployment is like a scientific experiment to guide decision-making on features and changes to an application. It involves two versions of a feature that are presented to different user groups to see which is preferred.

For example, if there's uncertainty about which design of a feature is more effective, A/B testing allows for real-time comparison. Each version is given to a separate segment of users, and their interaction with it is closely monitored. The team then uses this data to determine which version is more successful, based on specific metrics like user engagement or ease of use.

By making sure to use A/B testing where it's needed, software teams can keep tweaking their product bit by bit, ensuring it keeps up with what users want and need.

Wrapping up

Each deployment pattern stands out for specific strengths: Blue/Green for safety and zero downtime, Canary for controlled, low-risk rollouts, Rolling for maintaining continuous operations, Feature flags for flexible feature management, and A/B Testing for data-driven user insights.

The right deployment pattern varies depending on the project's needs and objectives. Recognizing these differences allows teams to choose the best approach for a successful and user-centric software release.

What Does an API Gateway Do? (Recap)

An API Gateway is a centralized entry point for client interactions with microservices, simplifying communication, enhancing security, and optimizing performance.

It handles request routing, validation, authentication, rate limiting, and protocol translation.

Additionally, it aggregates responses, monitors performance metrics, and provides logging, caching, and fault handling.

This makes it essential for managing complex microservices architectures efficiently.

See here, for how an API gateway processes a request.

SemVer Explained in Very Simple Terms

Semantic versioning is a standardized way to communicate software upgrades.

It categorizes changes into three buckets:

🔴 Major: Contains breaking changes that require users to upgrade their code or integration.

🟢 Minor: Changes are backward-compatible. Typically extends functionality or improves performance.

🟣 Patch: Contains bug fixes that don’t change existing functionality.

Pro tip: A simplified framework for thinking about SemVer is “Breaking.Feature.Fix”.

SemVer provides an easy and clear way to communicate changes in software, which helps manage dependencies, plan releases, and troubleshoot problems.

How the Most Prominent Git Branching Strategies Work (Recap)

When formulating your branching strategy, take the most relevant features from the strategies below and apply your own set of tweaks. Every project and team has its own unique needs and boundaries, which should be reflected in their Git branching strategy.

Feature branching: A popular method where each feature gets its own branch to ensure that changes are isolated and code reviews are simplified.

Gitflow: has two permanent branches — a production and a pre-production branch, often referred to as the “prod” and “dev” branches. Features, releases, and urgent bug fixes get temporary branches. It’s a great approach for scheduled releases and handling multiple production versions.

GitLab flow: A blend of feature and environment-based branching. Changes merge into a main branch, then to branches aligned with the CI/CD environment stages.

GitHub flow: Similar to feature branching but with a twist. The main branch is always production-ready, and changes to this branch set off the CI/CD process.

Trunk-based development: Branches are short-lived. Changes merge into the main branch within a day or two, and feature flags are used for changes that require more time to complete. This is ideal for large teams with disciplined processes.

Check out the full post here for an expanded explanation of the main git branching strategies.

That wraps up this week’s issue of Level Up Coding’s newsletter!

Join us again next fortnight where we’ll explore and visually distil more important engineering concepts.