DEV Community: Mark Phelps

️️Feature Flags 101: 3 Basic Feature Flag Use Cases You Can Implement Today 🏁

Mark Phelps — Mon, 29 Jan 2024 14:35:35 +0000

High-performing engineering teams ship quality code fast.

For that, they decouple code deployment from its release. This enables them to lower the risk of bugs in production and deploy code more often.

What is the best way to implement this?

Feature Flags.

They may seem complicated, but in this article, I'll show you how you can leverage them for different use cases and how Flipt makes the process easy and seamless.

Developers 👋

If you are looking to make high impact Open Source contributions in 2024, we have a step-by-step roadmap and an awesome community to help you with that.

Join 260+ Developers ▶

What are Feature Flags?
Use Case #1: Controlled Rollouts
- How can Flipt help?
Use Case #2: Experimentation & A/B Testing
- How can Flipt help?
Use Case #3: Permissions & Targeting
- How can Flipt help?
Wrap Up

What are Feature Flags?

Have you ever slipped a bug in production that caused:

App crashes
Regressions
Security Vulnerabilities

I have.

If you didn’t use feature flags, it’s likely that you rolled back the breaking change and deployed a new build. Or worse, fixed it forward causing extended downtime for users.

Feature flags enable controlled rollout of software by allowing developers to turn features on or off without deploying new code.

Let’s look at how they are useful in more detail.

Use Case #1: Controlled Rollouts

#1 rule of shipping reliable software?

Never break the build.

That’s how you build trust with your users.

To do this, you should roll out new features gradually to a small percentage of users, and then increase them over time. This gradual rollout helps in monitoring the impact and performance of the feature and reducing the risk.

How can Flipt help?

In Flipt there are two types of flags — variant and boolean.

You can perform rollout for both types of flags, using rules and distributions, for variant flags, and rollouts rules for boolean flags.

Flipt Boolean Flag Preview

Boolean flags are most commonly used when performing code rollout type operations if you want to slowly release functionality over time.

Use Case #2: Experimentation & A/B Testing

Imagine that you’re running an e-commerce platform. And you’re revamping your user interface. Wouldn’t you be interested in knowing its impact on sales and other key metrics?

Chances are you do.

And that’s where feature flags can help. You can experiment with the feature and gauge its impact on KPIs before launching it for all the users. Hence, limiting the negative impact caused by it.

Similarly, feature flags facilitate A/B testing by showing different features to different user groups, helping in understanding user preferences and behavior.

How can Flipt help?

Flipt Variant Flag Preview

In Flipt, experimentation is mostly accomplished through using variant flags, where you can, for example, return colorscheme: default to 80% of visitors to your application and then colorscheme: dark to the remaining 20%.

Use Case #3: Permissions & Targeting

In addition to controlled rollouts and experimentation, feature flags are also useful for targeting groups. It can be a

Group of users
Group of machines
Group of environments

These groups can be created based on any criteria.

E.g. If Uber wants to launch the UberEats feature, it’s less likely they will be doing it for all the cities that they operate in. More likely, they will launch it for a few cities first. Here, they can leverage feature flags which will be enabled only for users of a particular city.

How can Flipt help?

In Flipt you can use our powerful context evaluation along with segmentation to build pretty much any type of logic required for a specific group.

Flipt Segmentation Preview

This can be especially useful for developing ad-hoc permissions within your application, without requiring a more heavy-handed access control system or library.

Wrap Up

That’s it!

I hope you’ll use feature flags next time you encounter the above use cases.

And if you need any help with implementing Feature Flags, you can shoot your queries on our discord. We have an awesome community there 💗

If you found this valuable, follow me for more open-source related articles. 🙂

Also please give Flipt a ⭐️ on GitHub, it really helps us out!

️🚀 🚀 Top 3 GitOps Tools for Infrastructure Automation in 2024 🔨

Mark Phelps — Tue, 23 Jan 2024 14:47:25 +0000

In 2024, developers should primarily focus on their core tasks of feature development, fixing bugs and making improvements to the application.

That means less time spent on adding feature flags, managing infrastructure, monitoring deployments, etc.
Also, as per Puppet State of DevOps Report 2023, lack of automation has been one of the biggest pain points of platform teams.

So in this article, let’s unpack why your project needs infrastructure automation and share tools to help you get started.

Shall we?

Developers 👋

If you are looking to make high impact Open Source contributions in 2024, we have a step-by-step roadmap and an awesome community to help you with that.

Join 250+ Developers ▶

How Can Your Project Benefit From Infrastructure Automation?
Tool #1: Digger
Tool #2: Argo Project
Tool #3: Pulumi
Wrap Up

How Can Your Project Benefit From Infrastructure Automation?

Let’s go over some of the basic benefits of automating your infrastructure:

Ensure repeatable results every time. So that you can provide predictable and reliable experience to users and development teams.
Remove the need for (#clickops), engineers clicking around in a cloud provider UI. Automation improves process efficiency and agility by reducing manual effort. As a result, freeing up DevOps engineers from the tedious tasks.
Built in auditing. Keep a log of every operation done in your infrastructure. Comprehensive audit trails provide visibility into history of operations which is of great help at the time of debugging and troubleshooting.

Tool #1: Digger

If you want to simplify your infrastructure management and improve visibility and auditability of its changes, Digger might be worth exploring. It’s an open-source IaC automation and collaboration software for Terraform and OpenTofu.

Digger tool showing proposed infrastructure changes.

You can version control your infrastructure through defining it in code and storing it in the git repository. With automated infra provisioning and updates, Digger ensures consistency and significantly reduces manual effort of DevOps teams.

At the time of writing this article, Digger has ~2.5k stars on GitHub and is used by companies like Grab, McKinsey & Company, Duolingo with several others.

They also have a highly responsive community that will help you with roadblocks along the way.

Tool #2: Argo Project

Argo Project has become one of the top projects to manage Kubernetes clusters and workflows. Along with being able to run CI/CD pipelines natively, you can easily run compute intensive jobs like data processing in fraction of time.

With it’s rollouts tool, it provides advanced deployment capabilities such as:

Blue-green ✅
Canary ✅
Canary analysis ✅
Experimentation ✅

Also, Argo provides a declarative approach to application deployment that simplifies the deployment process and reduces the risk of errors.

Argo Tool to get more done with Kubernetes.

If you’re thinking, can Argo meet your advanced deployment requirements? Here’s a step-by-step tutorial by @pavanbelagatti on how to implement advanced deployment strategies:

Argo Rollouts: Unleashing Advanced Deployment Strategies

Pavan Belagatti ・ Aug 2 '23

#kubernetes #tutorial #devops #learning

Tool #3: Pulumi

Storing infrastructure as code is great but how to write code for one? Well Pulumi has solved that for you. It simplifies and automates your cloud infrastructure and optimizes for speed of releases.

Best part? You can do that in your familiar programming language with autocomplete, type checking and up-to-date documentation. Leaving no reason to procrastinate 😅

Pulumi AI responding to prompt.

Here’s what Matt Stephenson, Senior Principal Software Engineer at Starburst Analytics has to say about Pulumi:

Pulumi let us build and automate cloud infrastructure projects at a scale that simply wasn’t imaginable using prior-generation infrastructure as code technologies

Pulumi is truly your partner for scaling cloud infrastructure.

Wrap Up

That’s it!

Now, I hope these tools will help you in automating your project infrastructure.

If you need any help in setting up these tools, feel free to ping me on discord. We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

Flipt Follow

Flipt is an open-source, enterprise-ready, GitOps-enabled, CloudNative feature management solution. Manage features, experiments, and rollouts across multiple teams and environments without data leaving your infrastructure.

️🚀🚀 Top 3 DevOps Trends to Watch Out for in 2024 📈

Mark Phelps — Mon, 15 Jan 2024 14:46:18 +0000

Staying updated with trends is important to remain competitive and relevant in the industry.

As we stride into 2024, the landscape of DevOps Engineering will continue undergoing a transformative shift. The challenges we face — complex deployment workflows, information & access management of internal teams, and most importantly keeping tabs on what’s running in production — are more pressing than ever.

At Flipt, we continually discuss technologies that can bring change to the industry. In this article, we delve into cutting-edge top trends and tools that can redefine DevOps and platform engineering this year.

Let's go 🚀

Developers 👋

If you are looking to make high impact Open Source contributions in 2024, we have a step-by-step roadmap and an awesome community to help you with that.

Join 230+ others ▶

TL;DR

Trend #1: More eBPF tracing adoption
Trend #2: GitOps becoming mainstream
Trend #3: Internal Development Platforms everywhere

Trend #1: More eBPF tracing adoption

eBPF will remain trendy in 2024. It allows deep insights into kernel activity with minimal performance and impact. Tracing tools like bcc and bpftrace are becoming increasingly popular for troubleshooting performance issues.

Before, to get application tracing and performance metrics, you’d have to manually add and configure libraries such as OpenTelemetry in each application. This is painstaking and error-prone — as it requires application or DevOps engineers to do it for each new application they want to deploy.

Tools like Odigos have discovered a new way, leveraging eBPF to automatically add tracing to each request path as they make their way through your stack. This is a game changer as it gives much-needed time back to your engineers, reducing toil along the way.

Moreover, it’s open source and community-driven, providing readily available resources and support.

Trend #2: GitOps becoming mainstream

GitOps is another emerging trend in DevOps that emphasizes treating infrastructure as code and managing it through git repositories.

This approach leverages the familiar workflows and tools of Git for:

Deployments
Configuration changes
Infrastructure updates

At Flipt, we believe that the future is declarative. This means that you should quickly be able to see what state your application is in, but more importantly how it got in that state to begin with. GitOps solves this issue by using familiar tools like git, pull/merge requests, CI/CD to deliver configuration changes — instead of your engineers making API requests or clicking around in a UI (#clickops).

We believe this is the best way to manage all configuration data, even feature flags. That’s why, we’ve gone all in on supporting GitOps workflows at Flipt (with a lot more to come soon). We even have a guide to get you started.

In 2024, we'll see even more adoption of GitOps methodologies in larger organizations that are traditionally not early adopters, as the concept has proven itself to be a winner for smaller, more agile teams in previous years.

In a world of fast-changing requirements and business needs, GitOps enables DevOps teams to respond quickly.

Trend #3: Internal Developer Platforms everywhere

Finally, a trend that I am most bullish on in 2024 that leads to:

Faster CI/CD cycles
Streamlined workflows
Improved governance and compliance

is Internal Developer Platforms (IDPs).

// Detect dark theme var iframe = document.getElementById('tweet-851935087532945409-150'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=851935087532945409&theme=dark" }

These are web-based platforms that provide developers with self-service access to tools, resources, and environments needed for their work.

Building an IDP from scratch is hard work. That’s why projects such as Spotify’s Backstage and Port exist to help bring internal developer platforms to organizations without the time, budget & ability to build them themselves.

I prefer Port’s opinionated UI/UX over Backstage which requires you to write React components for new integrations.

Whichever tool your team chooses, giving developers a single place to control all aspects of your engineering platform — means less time responding to requests and internal issues from your platform team.

DevOps teams need IDPs for greater autonomy and efficiency.

Wrapping Up

That’s it!

Hope you’ll take advantage of these DevOps trends in 2024 and incorporate them into your workflow.

If you need any help with that, feel free to shoot your queries in our discord. We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

Flipt Follow

️🚀🚀 3 Must Know Tools for Top DevOps Engineers 👷

Mark Phelps — Tue, 09 Jan 2024 14:54:31 +0000

As a DevOps engineer you must have asked this question at least once:

How do I learn so many tools?

In this article, I will share the DevOps tools that we've used at Flipt and in previous roles (such as at InfluxDB). These tools are relevant for any modern software project.

Also, if you’re looking to make a DevOps related contribution to an Open Source project, this article will serve as a great source of inspiration for you.

Let’s dive in! 👇

Developers 👋

If you are looking to make high impact Open Source contributions, we have a step-by-step roadmap and an awesome community to help you with that.

Join 220+ others ▶

TL;DR

Tool #1: runatlantis/atlantis
Tool #2: argoproj/argo-cd
Tool #3: keyval-dev/odigos

Tool #1: runatlantis/atlantis

DevOps engineers spend lot of time in figuring how to integrate infrastructure changes seamlessly into the project’s development workflow.

And that’s where Atlantis comes in. It automates terraform workflows within pull requests. As a result it:

Prevents infrastructure drift
Enforces platform consistency
Improves collaboration b/w devs and platform engineers

At Influx we used Atlantis to manage applying our Terraform manifests used to build around 20 Kubernetes clusters across major cloud providers (AWS, GCP and Azure). Our infrastructure team owned our Terraform repositories and gave access to engineers across the organization to contribute via pull-requests in GitHub. Atlantis gave them the confidence and coordination needed to integrate these changes safely into our trunk branch and apply them to our multiple target environments.

Tool #2: argoproj/argo-cd

If you have worked with Kubernetes before, you know how much pain it is to manage app deployments and updates across multiple clusters.

But what if I tell you, there’s an easy way to setup an automation that:

Streamlines releases
Reduces manual errors
Enables faster time-to-market

That would be pretty incredible right?

Argo - which is an open source continuous delivery platform for Kubernetes does that for you.

At Influx we used Argo as our continuous delivery platform. Again we were deploying many applications to around 20 Kubernetes clusters across the three major cloud vendors. Argo helped to unlock trunk based development and continuously ship changes to production environments. Also, it gave us great visibility into the state of our delivery pipelines and their targets

Tool #3: keyval-dev/odigos

Lastly, a super useful tool for all DevOps engineers is Odigos. It allows you to monitor distributed applications using OpenTelemetry and eBPF.

Additionally, Odigos comes with:

Extreme Performance
Doesn’t require code changes
Automatically get traces, metrics and log

And the best part is it’s open source and built with an active community.

Highly recommended tool for your DevOps toolbox.

Wrapping Up

That’s it!

These are some of the top tools that every DevOps engineer should have in their toolkit in 2024.

Want to explore more DevOps tools like these? Join our awesome community of engineers where we discuss them regularly. 💗

If you found this valuable, follow me for more open source related articles 🙂

Flipt Follow

️🚀🚀 3 Open Source Contribution Ideas for DevOps Engineers💡

Mark Phelps — Tue, 02 Jan 2024 14:26:04 +0000

One of the toughest aspects of getting started with an open-source project is coming up with contribution ideas. And there’s little help online if you’re a DevOps Engineer.

But what if I told you that I have some ideas that you can implement in any project? It's true. The ideas that I will be sharing in this article apply to any open source project.

Before getting started, first understand why you should contribute to Open Source in the first place.

Why should you contribute to Open Source?
Idea #1: Modernize CI/CD Pipeline
Idea #2: Setup Dev Environments
Idea #3: Automate Issue/PR triaging
Wrapping Up

Why should you contribute to Open Source?

If you are new to open source, you might be wondering why I should do it at all. Here are a few ways making open-source contributions can help your career:

Learn new skills. You can work on a tech stack or a programming language of your liking, rather than one being used at work.
Showcasing your skills. You can add your open source contributions to your resume or portfolio. This serves as a proof of your skill — even if you didn’t use the tech in the current job.
Improve problem solving. By collaborating with developers and having community discussions over features/bugs, you gain a fresh perspective on how other developers solve problems.

Enough on the motivation. Now, let’s take a look at what actual contributions you can make to an Open Source project.

Idea #1: Modernize CI/CD Pipeline

If you’re looking to demonstrate your ability to optimize and automate processes in your resume, working on the project's CI/CD pipeline would be the best place to contribute.

A well optimized deployment pipeline will help projects with faster releases and updates. Hence, improving overall code quality and collaboration.

CI/CD is undergoing a major shift. There are several tools and startups out that are building the next generation of CI/CD.

We really love Dagger at Flipt, as it allows us to customize our CI/CD pipelines to our heart’s content, while ensuring that they can be reproduced on any machine (thanks to Docker).

No matter how well architected a project’s CI/CD pipeline is, there’s always room for improvement. For example, you could help a project speed up their builds by setting up dependency caching, or splitting up jobs to run in parallel. Any project maintainer would happily accept contributions that help speed up their project’s CI/CD pipeline.

Idea #2: Setup Dev Environments

One of the biggest challenges open source projects face is streamlining new contributors onboarding. With a dev environment, projects are easy to test and experiment. As a result, increasing overall project contributions.

Also, it’s a great way to gain experience with cutting-edge containerization tech, and deep understanding of project dependencies and setup.

There's a multitude of projects from startups and large companies like Microsoft that are aiming to simplify developer environments. A few of the ones we’ve tried include:

GitHub Codespaces
DevContainers (Runs A Codespace but on your local machine)
DevEnv.sh (Which uses Nix OS instead of Docker)

We support all 3 at Flipt, as we know developers have their own preferences, especially when it comes to their dev environments. Our goal is to allow new contributors to get up and running quickly, without limiting them to a specific toolset or workflow.

Ideas for contributing include:

Bootstrapping the setup these well-known tools in an OSS project
Updating dependencies (such as bumping base image versions)
Ensuring the dev environment works for new contributors, not just those who have worked on the project in the past.

Idea #3: Automate Issue/PR triaging

Issue tracking and collaboration aren’t going anywhere. So it’s better that you learn to do it right. Automating a project’s issue management is one way you can learn that.

Automated issue management helps the project by:

Faster issue resolution
Improved issue prioritization
Better project progress tracking

And project maintainers will love you for that.

Are you good at writing scripts? Want to build a GitHub bot? You could help project maintainers by helping them script the process of issue/PR triage to ensure:

Issues are marked according to the project’s standards (ie: always have bug or feature request label, etc)
Creating a GitHub bot to ping contributors if their PR is missing some key component (like test coverage or passing tests)
Propose and write a script to help ensure that there are always adequate amounts of Good First Issue labeled issues for new contributors to pick up

Flipt Project Good First Issues

I would suggest first opening an issue or discussion on any repo you would like to help automate, however. This will ensure that your contribution would fit with how the core team operates.

Wrapping Up

That’s it!

Now, you can choose any Open Source project of your liking and implement and start contributing.

If you need any help with that, feel free to shoot your queries on our discord. We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

️👨‍🔧 3 Tiny Fixes You Can Make To Start Contributing to Any Open Source Project 🚀

Mark Phelps — Thu, 28 Dec 2023 23:33:37 +0000

If you’re new to open source, the process can be overwhelming.

But after onboarding 50+ contributors to Flipt, I realized there are ways to make starts easy for newbies.

In this article, I will be sharing 3 fixes that you can make to ANY open source project to get started.

Best part is that these are quick and easy to make and are technology independent, so you can use them to contribute to any open source project.

Let’s dive in:

Fix #1: Fix a typo

Have you ever corrected:

A misspelled function name?
Grammatical errors in documentation?
Changed a variable name to a more accurate one?

If so, you can start your open source journey by doing the same.

Such typos are pretty common in an open source project. And due to them the project might appear unprofessional or not well maintained to its users. So even with a low effort change like this, you can improve the overall quality of the project.

Fun fact: We actually use a code linter via golangci-linter to catch misspellings in code/comments using client9/misspell.

Fix #2: Fix a broken link

We all have clicked on a link which leads to nowhere.
And if it’s a link to a critical resource like a tutorial or troubleshooting guide, it can be a frustrating and time consuming experience for the developers.

Broken links in your user-facing documentation not only make your project seem unprofessional, they also negatively affect SEO performance, making your project harder to find.

So, if you can find any non-functional links, or links guiding to the wrong location, fixing them will be a valuable contribution to a project.

Flipt pull request fixing broken link

With your small contribution, you can make a big impact by saving developer’s time and frustration.

This is a big reason why you should make your documentation source open also! We do this for our docs and it's paid off in spades.

Fix #3: Fix outdated documentation

Similar to broken links, stale documentation is another way to waste developer's time. They might waste time implementing or understanding an outdated piece of code.

Flipt pull request fixing outdated doc

Outdated documentation reduces confidence in your project especially for new users. Having docs that are incorrect/out of date puts an unnecessary roadblock in the way of users trying and integrating with your project.

Here’s some ways you can fix it:

Update outdated API descriptions
Correcting incorrect code examples
Removing references of deprecated code

This will contribute significantly to the project's long term sustainability and maintainability.

Wrapping Up

That’s it!

Now you can choose any open source project of your liking, and make the above valuable fixes to get started quickly.

If you need any help with that, feel free to shoot queries in the discord server.
We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

Flipt Follow

🔥 The Single Best Tip To Attract More Contributors To Your GitHub Project💡

Mark Phelps — Wed, 20 Dec 2023 00:42:16 +0000

Picture this.

You are excited to contribute to an Open Source project. You go to its GitHub repository. Look at active issues. Only to wonder if you’d be able to complete the task. And then never came back to it.

If it has happened to you, you’re not alone.

Most first-time contributors struggle to find issues that match their skill level or the time they want to give to the project.

In this article, I will share the effort-based issue labeling system we use at Flipt to deal with this problem.

Implementing this will help you get more contributors to your open-source project. Also, get more contributions from existing ones.

Too good to be true? Let’s find out.

TL;DR

Why labeling issues by effort level is a good idea?
Effort Level #1: extra small
Effort Level #2: small
Effort Level #3: medium
Effort Level #4: large
Effort Level #5: extra large

Why labeling issues by effort level is a good idea?

Before going over our system, let’s explore some benefits of labeling issues with effort estimation:

Confidence to contribute: Effort estimation helps contributors choose tasks that match their time and skill level. This motivates them further to participate.
Low barrier to entry: New or inexperienced contributors can make meaningful contributions to the project by working on low-effort issues.
Encourage a shared understanding of the project: Effort labels boost transparency between maintainers and contributors, as it makes clear the time commitment required for each issue.

Now let’s understand the estimation labels that we assign to the issues. These are ordered from low to high effort levels, which is also a recommended order in which new contributors should be making contributions to the project.

Effort Level #1: extra small

Flipt GitHub Issues labeled xs

These are the issues that contributors can complete within minutes to an hour. They are ideal for first time project contributors to get started.

Example:

[FLI-746] Show time/date format on settings/preferences page #2535

markphelps posted on Dec 13, 2023

Problem

It would be nice to show what setting the value of 'UTC' or 'local' actually looks like in the UI on the settings page

Right now there's no clear indication of what the change means until you goto a list page

Ideal Solution

Here's an example mockup:

Here we would show the current date/time and then live update it's format depending on what the user checked

Search

[X] I searched for other open and closed issues before opening this

Additional Context

No response

From SyncLinear.com | FLI-746

View on GitHub

Effort Level #2: small

Flipt GitHub Issues labeled sm

Issues labeled with sm, can take multiple hours to complete but less than a day. Such issues are great for new contributors that have solved a couple of xs issues or contributors that find xs issues too trivial.

Example:

Namespace input validation not updating button until clicking outside of input #2546

julesglad posted on Dec 17, 2023

Problem

New namespace validation only updates button state upon clicking outside of the input, rather than on each keystroke. This does not prevent the feature from working, but can cause some confusion for the user.

Because I have not clicked out of the input, and instead gone directly to the button to create the namespace, even though I have a special character inside of the input, it has not yet updated to give me a validation error.

Ideal Solution

Button state should be updated on each keystroke.

Search

[X] I searched for other open and closed issues before opening this

Additional Context

No response

View on GitHub

Effort Level #3: medium

Flipt GitHub Issues labeled md

These issues are not too big, not too small. Work involved here can span a couple of days. That makes it an ideal option for weekend open source contributions.

Example:

[FLI-738] Validate authentication configs at start #2532

markphelps posted on Dec 12, 2023

Problem

Authentication configs are not currently fully validated at Flipt startup

For example this config:

authentication:
  methods:
    github:
      enabled: true
      scopes:
        - "user:email"
        - "read:org"
      allowed_organizations:
        - "flipt-io"

Allows Flipt to start up just fine, however, its not a valid config since client_id, client_secret and redirect_address are all required for the OAuth setup with GitHub: https://www.flipt.io/docs/configuration/authentication#github

Ideal Solution

Now that we have per authentication method validation (added https://github.com/flipt-io/flipt/pull/2508/files#diff-9b81b9c76a5ad1bd617096d6af8c6bed965ca6c6b2505ce329d9d74151d0709cR257), we should now define the minimum set of required configuration for each authentication method and then add validation for each auth method we support so that Flipt will not start and warn the user of the invalid/missing fields.

Search

[X] I searched for other open and closed issues before opening this

Additional Context

No response

FLI-738

View on GitHub

Effort Level #4: large

Flipt GitHub Issues labeled lg

lg issues are a little bit big. It’s recommended for active contributors or contributors that have fixed multiple md issues. Simply due to the level of communication involved on these issues.

They might also span the frontend and backend.

Example:

Support k8s-friendly gRPC deployments #2428

jalaziz posted on Nov 22, 2023

Problem

I'll start by saying that I was hoping to contribute this myself, but haven't found the time yet. I may get to it this coming weekend, but figured I should file an issue first.

Deploying gRPC services on Kubernetes is notoriously troublesome without a service mesh. The problem is that gRPC uses HTTP/2 and the clients establish long lived connections which kube-proxy doesn't know how to load-balance.

Expecting users to use service meshes or linkerd is not very realistic. It turns out that there is another way, but it requires various things to be configured. The general steps are:

Set keepalive timeout parameters on the server to force periodic re-resolution of DNS on the client.
Deploy the server as a k8s headless service.
Configure the client to use DNS round-robin load balancing (e.g. dns:///flipt -- the third slash is significant)

This blog post has plenty of extra info.

For Flipt, I believe the changes required would be:

Add the keepalive parameters to the server.
Introduce a new headless k8s service to the helm chart (this allows the HTTP service to continue to be load-balanced by kube-proxy)

Ideal Solution

Both the flipt gRPC server and the helm chart should support client-side load balancing out of the box.

Search

[X] I searched for other open and closed issues before opening this

Additional Context

No response

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/flipt-io/flipt/issues/2428">View on GitHub</a></div>

Effort Level #5: extra large

Flipt GitHub Issues labeled xl

Finally, xl issues are as big as it gets. These issues are rare and are recommended for contributors that have previously made successful lg level contributions. As such contributions will need deep understanding of the project and skill proficiency.

Usually these issues represent larger projects or initiatives that will need to be broken down into smaller ones before starting work. These issues are helpful to get feedback or suggestions from the community.

Example:

[FLI-734] Proposal(Auth): Support JWTs #2511

markphelps posted on Dec 10, 2023

Support externally created JWTs, verifying via these methods:

PEM-encoded key file
JSON Web Key Set (JWKS) in a local file
JWKS provided by the configured JWKS endpoint

Need to flesh this out a bit more, but here are some good references to get started:

From SyncLinear.com | FLI-734

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/flipt-io/flipt/issues/2511">View on GitHub</a></div>

Wrapping Up

That’s it!

Now, you can use this simple-to-implement system in your GitHub project to boost contributions.

If you need any help with that, feel free to shoot queries in the discord server.
We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

🚀 🚀 Level Up Your GitHub Project with these Must-Have Bots 🤖

Mark Phelps — Fri, 15 Dec 2023 13:55:18 +0000

My life as an open-source maintainer:

Before - Tiring & Stressful

Second - Exciting & Fun

The difference?

Using bots at work.

In this article, I will share 3 bots that work for us 24x7, making our maintainer’s life easy.

These bots will automate the common repetitive & manual work of an Open Source project maintainer, so that they can focus on the project.

Let’s go! 🚀

Quick Ad
Hey 👋, If you are looking to network with open-source contributors and maintainers, then join our discord. See you there!

TL;DR

Bot #1: AllContributors
Bot #2: Kodiak
Bot #3: CodeCov

Bot #1: AllContributors

Recognizing and thanking contributors to your Open Source project is non-negotiable. It’s easy to miss non-code contributions as they get less visibility than code contributions.

Before AllContributors we had no way of publicly thanking contributors, other than simply commenting ‘thanks’ in the PR. This meant that most contributions went unnoticed by the larger community.

AllContributors solves this for maintainers.

It automates the process of recognizing new contributors, by adding them to the project's README file, with mention of their contributions.

This way you acknowledge the work of all kinds of contributions, developers, designers, documentation writers, etc

How cool is that?

After a PR is merged, I simply comment @allcontributors-bot please add @user for [x], where x can be code, docs, etc.

Comment for #2474

markphelps commented on Dec 02, 2023

@all-contributors please add @AmineRhazzar for code

View on GitHub

Then the bot takes over from there, putting up a new PR to add the user’s picture and info in the Contributors section of our README.

Use this bot to improve contributor visibility. It’s a one-time investment that will pay high dividends for years. Follow this guide for the exact steps.

Bot #2: Kodiak

Outdated project dependencies lead to security, stability, and performance-related issues, which is why dependency updates must be patched promptly.

At Flipt, we’ve used Dependabot since it was launched to keep our dependencies up to date. Dependabot is great about opening PRs for updating dependencies. The problem however is that it opens too many for us to keep track of and merge manually.

Kodiak automates branch updates and merges of your project. It automatically merges pull requests once a set of criteria are met.

This reduces the chance of any regression caused by outdated dependency in the project.

Kodiak handles the busy work of updating PRs that have become out of date from ‘main’ and merges any PRs that were created by Dependabot and have all green checks ✅. This means that we as maintainers get our time back to focus on reviewing PRs from humans, not robots 🤖

You can add Kodiak to your project in minutes. And it will save hours of maintainers' time and effort.

Bot #3: CodeCov

The better your project’s code quality, the more high-quality contributions you’ll receive from the contributors. Which is why it’s important to monitor the project’s code coverage.

Before integrating CodeCov, we would need to:

Checkout each PR locally
Run the test suite with coverage enabled
Manually comment on the PR where coverage was missing. This was a huge pain and a waste of time.

Now, CodeCov gives us actionable insights into test coverage and integrates well with our GitHub project.

The best part is, that once you integrate it in your CI pipeline, it automatically checks code coverage with each build.

It also highlights areas of your project that lack test coverage. So that you can prioritize which tests need to be written first.

Now, CodeCov handles reporting on our PRs where coverage is missing, notifying contributors (and ourselves) where we might be lacking tests.

It also adds a GitHub check that we can make required, to ensure that a changeset is increasing test coverage, not decreasing it.

Codecov has a quick start guide to help you in getting started.

Wrapping Up

That’s it!

Hope that these bots will supercharge your maintainer productivity.

Join our discord to network with other maintainers & developers.
We have an awesome community there 💗

If you found this valuable, follow me for more open source related articles 🙂

Harnessing the Power of Testcontainers for Robust Testing in Go

Mark Phelps — Wed, 13 Dec 2023 21:32:57 +0000

Testcontainers for Go is a Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers that should be run as part of a test and clean up those resources when the test is done.

https://golang.testcontainers.org/

Why Testcontainers?

Testing is a critical phase in software development. While there are many different types of testing, the two that most developers are familiar with are Unit Testing and Integration Testing.

Traditionally, Unit Tests test code at the function level, while Integration Tests test code as it interacts with various external systems and dependencies, ensuring that all of the components of an application work seamlessly together.

Purists would argue that any test that requires an external dependency is an Integration Test. However, I've come to believe that at the end of the day, it doesn't matter what you call the type of test, just that your application is well tested, covering the various real-world scenarios that can occur.

This is where Testcontainers really shines. You can set up almost any scenario that you can think of for your tests that interact with external dependencies, and control those scenarios with Go code!

Set Up

Installation

To get started with Testcontainers-Go, you'll need to have Docker installed on your system. Then, installing the library is straightforward. Simply run:

go get github.com/testcontainers/testcontainers-go

This command fetches the library and adds it to your project.

Writing Your First Test

Let's imagine your application requires PostgreSQL. Instead of setting up a PostgreSQL instance manually in CI or on your local machine, you can use Testcontainers-Go to create a Docker container for PostgreSQL only for the duration of your test.

Here’s a simple example:

package main

import (
    "context"
    "database/sql"
    "log"
    "testing"

    "github.com/testcontainers/testcontainers-go"
    "github.com/testcontainers/testcontainers-go/wait"
)

func TestPostgreSQLContainer(t *testing.T) {
    ctx := context.Background()

    // Define the container request
    req := testcontainers.ContainerRequest{
        Image:        "postgres",
        ExposedPorts: []string{"5432/tcp"},
        Env:          map[string]string{"POSTGRES_PASSWORD": "password"},
        WaitingFor:   wait.ForLog("database system is ready to accept connections"),
    }

    // Start the container
    postgresContainer, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
        ContainerRequest: req,
        Started:          true,
    })
    if err != nil {
        log.Fatalf("Failed to start container: %s", err)
    }
    defer postgresContainer.Terminate(ctx)

    // Connect to the database
    port, _ := postgresContainer.MappedPort(ctx, "5432")
    db, _ := sql.Open("postgres", fmt.Sprintf("host=localhost port=%s user=postgres password=password dbname=postgres sslmode=disable", port.Port()))
    defer db.Close()

    // Your test logic here
}

In this example, we create a PostgreSQL container and wait for it to be ready. We then connect to the database and perform our test operations.

How to Leverage Testcontainers

Now that you can spin up a PostgreSQL instance for each test, you can do things like simulate what happens if PostgreSQL becomes unreachable by programmatically pausing or stopping the container while your application is in the middle of a database operation. This action can be easily done through Testcontainers-Go's control over the Docker container lifecycle.

By pausing or stopping the container, you simulate a network failure or a database crash. Your test code would then observe and assert the behavior of your application under these conditions. Key aspects to look for include how the application handles the loss of connection (e.g., does it retry, how does it log the error, does it alert the user?), and how it recovers once the database connection is re-established. This process would be repeated under various conditions and configurations to thoroughly test the application's resilience and error-handling mechanisms.

Conclusion

Testcontainers offers a robust solution for testing more complicated scenarios in Go applications. Its ability to create and manage Docker containers on the fly streamlines the testing process, making it more efficient and reliable. Whether you're dealing with simple database interactions or complex microservice architectures, Testcontainers-Go is a tool worth integrating into your testing suite.

Interested in seeing Testcontainers in a real-world project?

Check out Flipt, an enterprise-ready, GRPC-powered, GitOps-enabled, feature management solution written in Go where we make heavy use of Testcontainers for our tests.

3 Reasons Why You Should Contribute to Open Source in 2024

Mark Phelps — Mon, 11 Dec 2023 01:21:34 +0000

2024 will be the 12th year since I made my first open source contribution.

Since then I have:

Contributed to a global scale infrastructure GitHub Container Registry
Built a network of friends from all over the world
Started an Open Source Company

In this article, I will share the top 3 out of my 9934 reasons to start contributing to open source.

If you’re looking to learn new skills, and grow your professional network and career while working on projects you care about, just hear me out for the next 3 minutes.

Let’s dive in! 🚀

TL;DR

Reason #1: You can work on whatever you want
Reason #2: You can create value for other people
Reason #3: You can showcase your skills
Wrapping Up

Reason #1: You can work on whatever you want

With open source, you get the freedom to work on projects that you are passionate about. You can explore your interests, and learn new skills, without needing to meet a deadline.

This is very different from usual corporate work i.e. mostly closed source. And you are restricted to working on a specific set of technologies. In the long term, it can impact your technical growth and ability to adapt to industry changes.

It doesn’t need to be that way.

Take it from me. In previous roles, I was working in languages that I wasn’t interested in. I literally felt like my skills were stagnating. As a result, I was falling out of ‘love’ with programming.

But then I started working on open source projects in my spare time. And boy that helped. I was free to learn new languages and work on projects exciting to me.

Getting started with open source was one of the best decisions of my life!

And the best part is you can start small and slowly ramp up at your own pace. At Flipt, we have good first issues specifically for first-time contributors.

All you need to do is show your interest by commenting on the issue and we will help you out in making your first contribution.

Isn’t that amazing? 🙂

Reason #2: You can create value for other people

Right now, you are sitting on a lot of static knowledge that you have gained over the years with your professional and personal experience. Open source provides you an active community of developers who you can share it with and make a positive impact on the project.

It’s one of the most fulfilling things you’ll do as a developer. I’ll take the case of our contributor Andrew Hobson as an example.

feat(fs/s3): Initial support for s3 filesystem backend #1900

ahobson posted on Jul 24, 2023

This follows the same pattern as fs/git to add support for fetching feature flag data from S3.

In an AWS environment, this would allow deploying a readonly container and not require communication to a git repository outside of the deployment environment.

Let me know if you have suggestions or thoughts on how to improve the implementation.

Thank you for flipt.

Testing

The unit tests take advantage of an existing s3 bucket, using minio to simulate it locally.

Just like for the git backend, the mage dagger:run test:unit does the work to start, provision and configure the test suite appropriately.

However, if you do want to run this test locally to experiment or investigate, you can always do the following:

# in one terminal session
docker run -it --rm --name minio \
  -e MINIO_ROOT_USER=user -e MINIO_ROOT_PASSWORD=password -p 9009:9009 \
  quay.io/minio/minio:latest server /data --address ":9009"

# in another session first use the minio provisioner binary
# this pushes the contents of the provided directory into a bucket in minio
AWS_ACCESS_KEY_ID=user AWS_SECRET_ACCESS_KEY=password \
  go run ./build/internal/cmd/minio/... -minio-url http://localhost:9009 -testdata-dir ./internal/storage/fs/s3/testdata

# then you can run the test for `fs.Source`
AWS_ACCESS_KEY_ID=user AWS_SECRET_ACCESS_KEY=password TEST_S3_ENDPOINT=http://localhost:9009 \
  go test -v ./internal/storage/fs/s3/...

View on GitHub

This past summer, he implemented an entirely new s3 object storage backend for our project, because it was something he wanted to use in his daily work. As the main developer of the project, it’s probably not something I would have ever thought of, but now this backend is used by many of our end users and has inspired additional functionality!

Now you must be wondering — “But I have nothing to share”.
And I bet you have. You’re just blinded due to that knowledge being “obvious” to you now. However, when you see anyone struggling in the community with the same problem, you’ll be able to help them out with ease. And build valuable connections in the process.

Not sure still? Join our close-knit community to see it in action.

Reason #3: You can showcase your skills

Lastly, open source is one of the best ways to collect social proof.

You collaborate with the community, communicate on issues and features, and ship your code. You become a “low-risk” hire for any employer in comparison to one with just a resume.

Your contributions will bring you visibility and recognition that can potentially lead to job opportunities, consulting & speaking gigs, etc

// Detect dark theme var iframe = document.getElementById('tweet-1728963251294089254-635'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1728963251294089254&theme=dark" }

Our own George MacRorie recently was invited to give a talk at GitOps Con because of his amazing work on one of our open source projects.

At Flipt we give regular shoutouts and appreciate our contributors. We are grateful for each and every contribution made to the project. These contributions have helped us scale 3K supporters on GitHub.

So are you ready to showcase your technical expertise to the world?
Make your first contribution at Flipt and we’ll take care of the rest.

Wrapping Up

That’s it!

I hope this list sold you on making your first open source contribution soon.

Join our discord if you need help with that.
We have an awesome community there 💗

If you liked this post, follow us for more of open source related articles 🙂

3 Basic Traits That Every Successful Open Source Developer Has

Mark Phelps — Fri, 08 Dec 2023 14:04:10 +0000

Flipt has reached 3k GitHub stars ⭐ this week.

Woohoo!! 🎉

So I thought it would be a great time to reflect on what got us here and share our learnings with the community.

In this post, I’m sharing 3 traits of our awesome contributors that helped us scale Flipt this far.

These 3 skills will help you level up your open source collaboration game and make you an invaluable contributor!

Let's dive in 🚀

TL;DR

Trait #1: Communication
Trait #2: Empathy
Trait #3: Flexibility

Trait #1: Communication

Most open source developers find collaboration hard at first.

Documenting code changes
Participating in discussions
Sharing their point of view

None of this comes naturally.

But clear communication is a must for shared understanding and reducing wasted effort in the project.

Erka, who’s a regular contributor at Flipt, communicates well while collaborating with maintainers by:

Opening draft PRs
Having a discussion before full review
Actively responding to the feedback

Erka's contributions were vital in the past couple of releases.

Likewise, the more you find opportunities to communicate, the easier it becomes.

So, use commit message descriptions, review comments, code documentation, etc to develop your communication skills.

Trait #2: Empathy

When you don’t consider other contributor’s perspectives, you are limiting your learning.

You’ll be able to resolve issues much more effectively, when you promote a positive and inclusive environment.

One way to do that is like my fellow teammate George:

He literally checks up on PRs to unblock contributors. And offer a helping hand wherever he can.

Having active contributors like him makes it immensely easy for newbies to get up and running with Flipt.

So contribute to active project discussions or PR reviews to understand different contributor viewpoints.

It builds a strong foundation for the long-term growth of the project.

Trait #3: Flexibility

When you are open to feedback and suggestions, you:

Stay updated with latest trends
Become fun to collaborate with
Learn to navigate uncertainty & ambiguity

At first, Amine wasn't sure what to do with a particular bit of implementation. But they didn't let it block them.

They went ahead with what they thought was best, but were open to feedback and to make any changes if necessary.

That's why the easiest way to develop flexibility is by actively asking for feedback. Be open to constructive criticism. And use it to improve your approach.

Doing that will also help you in reducing stress and burnout caused by unexpected situations.

Wrapping Up

That’s it!

Hope you found it useful.
Leave a ⭐ to support our work at Flipt.

Drop in comments which trait you struggle with the most. 👇

Save 500+ Hours of Maintenance Work With These 3 GitHub Actions

Mark Phelps — Sun, 03 Dec 2023 13:32:54 +0000

GitHub Actions are awesome.

They help you ship high-quality software more quickly, without spending a lot of time and effort in the process.

In this article, I’m sharing 3 GitHub Actions we use at Flipt that saved us more than 500 developer hours.

You can use these battle-tested actions and automate your GitHub workflow right away.

Let’s get rolling! 🚀

TL;DR

GA #1: bufbuild actions
GA #2: devcontainers/ci
GA #3: goreleaser/goreleaser-action

GA #1: bufbuild actions

For background, we at Flipt are heavy users of protocol buffers and GRPC. We offer both a GRPC and REST API for communication between Flipt and our user’s services.

In the early days, working with GRPC and Protocol Buffers was a pain. You had to:

Make sure that you have the right versions of protoc (the protobuf compiler)
Correct GRPC extensions to generate code for your language of choice.
Be extremely careful about adding, updating, and deleting fields or messages in your GRPC protobuf files. Because doing something incorrectly would break backward compatibility for your users.

Now, Buf allows us to automate all of this toil by:

Generating code for our GRPC SDKs
Linting to make sure we don't break backward compatibility.

Here’s how we use Buf in our GitHub Actions:

We push new proto changes to the Buf Schema Registry after linting and running breaking changes checks.
After each release of Flipt, we trigger workflows for all of our GRPC SDKs to pull the latest changes from the BSR (above).
Then generate and publish new versions of our GRPC SDKs. (e.g. C# GRPC SDK)

Link to full code

This action automates the process of linting, publishing, and code generation saving hours if not days of manual work.

GA #2: devcontainers/ci

Every maintainer wants a consistent environment for contributors to develop and test their code.

But setting up & provisioning devcontainers can be a challenge when done manually. And that’s where devcontainers action comes in.

It creates and manages devcontainers for GitHub repositories. With this action, you can run commands for:

CI
Testing
Building, etc

We love devcontainers and GitHub Codespaces at Flipt.

They are an easy way to standardize a development environment for contributors. Using codespaces, contributors can get a running developing Flipt right from the GitHub UI.

If a contributor doesn’t want to use or pay for Codespaces, they can also run our devcontainer locally using VSCode + Docker.

There’s one challenge with devcontainers though.

Keeping a devcontainer configuration up to date. Especially for a constantly changing project like Flipt.

We solved this by leaning on the devcontainers/ci action to build our devcontainer each day. Now we can quickly resolve any issues with the build.

Trust me, using this action is a no-brainer.

GA #3: goreleaser/goreleaser-action

Goreleaser action makes it too easy to build, package, and publish Go binaries.

Additionally, you can:

Cross-compile your Go project for multiple architectures
Release to GitHub, GitLab and Gitea
Create nightly builds
Push to Homebrew, DockerHub, Snap packages
Create announcements for new releases on Twitter, Discord, Slack, etc

Goreleaser saves us so much time and effort it’s unreal.

Flipt binaries are published for 3 different architectures — amd64, x86_64, and arm64.

Also, to keep the MacOS Gatekeeper process happy, we need to sign and notarize the binary of our MacOS (arm64) builds.

We leverage GoReleaser (Pro) to:

First run two build workflows in parallel (one for Linux and one for MacOS)
And then merge the two results into a single job for publishing to GitHub Releases and DockerHub/GHCR/Homebrew.

If you’re interested, we have documented our entire release process here.

If you’re maintaining a Go project, always, always, use Goreleaser and spend saved time on more productive tasks.

Wrapping Up

That’s it!

Hope you found the list useful.
Leave a ⭐ to support our work at Flipt.

If you liked this post, follow us for more of open source related articles 🙂

DEV Community: Mark Phelps

️️Feature Flags 101: 3 Basic Feature Flag Use Cases You Can Implement Today 🏁

Developers 👋

Table of Contents

What are Feature Flags?

Use Case #1: Controlled Rollouts

How can Flipt help?

Use Case #2: Experimentation & A/B Testing

How can Flipt help?

Use Case #3: Permissions & Targeting

How can Flipt help?

Wrap Up

️🚀 🚀 Top 3 GitOps Tools for Infrastructure Automation in 2024 🔨

Developers 👋

Table of Contents

How Can Your Project Benefit From Infrastructure Automation?

Tool #1: Digger

Tool #2: Argo Project

Argo Rollouts: Unleashing Advanced Deployment Strategies

Pavan Belagatti ・ Aug 2 '23

Tool #3: Pulumi

Wrap Up

Flipt Follow

️🚀🚀 Top 3 DevOps Trends to Watch Out for in 2024 📈

Developers 👋

TL;DR

Trend #1: More eBPF tracing adoption

Trend #2: GitOps becoming mainstream

Trend #3: Internal Developer Platforms everywhere

Wrapping Up

Flipt Follow

️🚀🚀 3 Must Know Tools for Top DevOps Engineers 👷

Developers 👋

TL;DR

Tool #1: runatlantis/atlantis

Tool #2: argoproj/argo-cd

Tool #3: keyval-dev/odigos

Wrapping Up

Flipt Follow

️🚀🚀 3 Open Source Contribution Ideas for DevOps Engineers💡

Table of Contents

Why should you contribute to Open Source?

Idea #1: Modernize CI/CD Pipeline

Idea #2: Setup Dev Environments

Idea #3: Automate Issue/PR triaging

Wrapping Up

️👨‍🔧 3 Tiny Fixes You Can Make To Start Contributing to Any Open Source Project 🚀

Fix #1: Fix a typo

Fix #2: Fix a broken link

Fix #3: Fix outdated documentation

Wrapping Up

Flipt Follow

🔥 The Single Best Tip To Attract More Contributors To Your GitHub Project💡

TL;DR

Why labeling issues by effort level is a good idea?

Effort Level #1: extra small

Problem

Ideal Solution

Search

Additional Context

Effort Level #2: small

Problem

Ideal Solution

Search

Additional Context

Effort Level #3: medium

Problem

Ideal Solution

Search

Additional Context

Effort Level #4: large

Problem

Ideal Solution

Search

Additional Context

Effort Level #5: extra large

Wrapping Up

🚀 🚀 Level Up Your GitHub Project with these Must-Have Bots 🤖

TL;DR

Bot #1: AllContributors