Forem: DevCycleHQ

Developer Spotlight: Nika Salamadze

Andrew MacLean — Fri, 31 Mar 2023 00:41:03 +0000

Q: Where did you go to school/what is your background in engineering?

A: I took my first course in programming in Grade 10, and knew I wanted to pursue a career in engineering from that point forward. I graduated from the University of Waterloo with a degree in Computer Engineering in April 2022. DevCycle is my first full time Engineering job, but I had multiple co-ops throughout university.

My first co-op was as an iOS developer for a startup called Marlena Books. After that, I was a Mobile Developer at an innovation hub for the Royal Canadian Air Force. My next co-op was as a Full Stack Developer for another start up called CharityCAN. I was then a Full Stack Engineer Intern for Harled, Inc, and lastly a Software Developer Intern for D2L before landing my full time role with DevCycle & Taplytics.

Q: What's your favourite thing you've ever built or worked on as an engineer?

A: During my co-op with the innovation hub for the Air Force, I worked on a product that started out very small, and eventually had a ton of impact and reach. It was a flight planning product that was initially meant to be used by a few squadrons in one of the wings of the Air Force, but then it became mandated and is now being used by nearly all of the Air Force.

It was really cool to know that I was working on something so impactful as an intern -- that doesn't always happen in internships/co-ops!

Q: What is one tool in your current stack that you could not live without?

A: DevCycle! Primarily because it allows me to release code with confidence. It gives me peace of mind knowing that I can disable entire code paths in production (without having to deploy a new build) in case there's a bug, a security vulnerability, or if users just don't like a feature.

Q: Which programming language are you most familiar with, and which do you prefer?

A: I work mostly with Javascript and Typescript, so that's what I'm most familiar with right now. During my earlier programming days (back when I thought I was going to be a game developer) I probably would've said C++.

Q: If you could give any engineering related advice to your younger self, what would it be?

A: Don't overthink it! Not every line of code you write will be perfect, so try to find a balance between being efficient and writing clean, easy to maintain, scalable software.

Q: Where do you go to stay up-to-date on all things engineering?

A: Social media, primarily Twitter and TikTok! TikTok is quickly becoming a resource hub for developers. One account that I've found particularly useful is Steve from Builder.io. @steve8708

Q: What's your least favourite thing about being an engineer?

A: There isn't much I don't like about being a developer, but if I had to pick something I'd say that it can get exhausting sitting in front of a computer for long periods of time. Especially when working remotely, since you're by yourself and it's easy to get caught up in a task and forget to take breaks.

Q: What's your favourite part about your job/being an engineer?

A: Being able to actively solve problems is the most fun thing about it for me. We're always facing new and interesting challenges in this role, so there is always something to motivate you to learn more and get better.

Q: What's your coffee order, and where's the best place to get that coffee from?

A: I mainly drink coffee for energy (I don't really enjoy the taste of it) so my order is usually just a regular black coffee.

Q: What's your favourite music type or band, and where do you listen to your music?

I use Spotify for all of my music. If I'm at the gym, I'll listen to Rock, Punk, Alt. But when I'm working, I'll listen to something that's more low-key like HipHop, Pop, Folk, or Country. I don't really stick to one genre--my music taste varies depending on what I'm doing.

Want to be featured in our next Developer Spotlight? Fill out this form!

Developer Spotlight: Jamie Sinn

Andrew MacLean — Wed, 29 Mar 2023 22:00:07 +0000

For this month's Developer Spotlight interview, we sat down with our very own Infrastructure Engineer, Jamie Sinn!

Q: Where did you go to school/what is your background in engineering?

A: My involvement in the engineering community and interest in engineering stems all the way back to participating in FIRST Robotics Competitions as a kid. FIRST really guided me towards hands-on engineering projects and helped me grow my engineering network over the years.

I’ve been programming since I was a young kid, with a heavy focus on backend/performance systems, as I never really had the skills for design/frontend development. Because I loved breaking things and fixing them, I soon realized I was most interested in infosec, and I ended up getting an Honours Bachelor of Information Systems Security at Sheridan College.

While I was still a student, I had my favourite internship at FIRST headquarters where I worked on security, and for the competition itself like game design for the 2020 FRC season!

Q: What’s your favourite thing you’ve ever built or worked on as an engineer?

A: DevCycle. We launched DevCycle after I joined the company, so I’ve been involved in the core architecture from the beginning, which is always a really special process. I’m also truly putting my effort behind something that I think is really valuable here. We have the power to shift the accessibility of feature flagging and make it something as standard as unit testing in a developer’s workflow, which I think is super impactful.

Q: What is one tool in your current stack that you could not live without?

A: Probably any Jetbrains IDE. I’ve used them for 10+ years, and (in my opinion) they are the best IDE you can get for most cases (Visual Studio would be the exception IMO). We use Macs here at DevCycle, and Jetbrains provides the most consistent experience across Windows and OSX which helps streamline your entire workflow, and makes the developer experience really positive.

Q: What are you learning right now?

A: Development wise, I’m currently trying to learn Rust, and expanding my experience with Go. I’m able to learn these mostly through books – I can usually read the book, and just start building projects in that language and learn from trial and error. I highly recommend any books by No Starch Press for this kind of stuff!

Outside of the development world, I’m trying to push my non-engineering knowledge towards some business validation stuff, which is important in a security role like mine to help our senior leadership team make decisions.

Lastly, I’m done with my PADI Open Water Diver course! I’ve been taking the course for the last few months and the final step is open water diving. (I’m probably going to complete it sometime in May, given that we live in Canada and I’d rather not dive in the lake right now.)

Q: If you could give any engineering related advice to your younger self, what would it be?

A: Don’t give up when you’re told no – find a different way to pose the question.

‍Q: What do you do to get "unstuck" on a really difficult problem or bug?

A: I usually try to find out how a similar problem has been solved in a different language or with a different use case. We don’t work in vacuums – the engineering world has more solutions than problems, so looking at other examples and making use of shared resources is always a good option.

Q: Describe your best (physical) environment to code in.

A: 3 monitors, a keyboard with mechanical switches, a mouse, a good ergonomic chair (specifically my Autonomous ergochair), and most importantly, no white lights (warm lights and yellow tones are better for me).

Q: What’s the largest roadblock or challenge you’ve ever had to navigate in tech?

A: Years ago, I built a tool that’s a networking router that automatically configures itself based on certain networking environments you have. When building it, I had no physical access to (or ability to) simulate every possibility of it, so I had to make a lot of calculated guesses. As a result, it still doesn’t work to the best of its ability today. But it’s still solid given the limited access/ability I had while building it.

Q: What’s your least favourite thing about being an engineer?

A: You’re always working. Your head is always focused on how to solve the next problem, and sometimes the solutions will come to you in unlikely and undesirable situations (i.e. in the middle of the night when you’re trying to sleep). This is true for both work, and not work problems!

Q: What’s your favourite part about your job/being an engineer?

A: You’ll never have the same problem twice. Even though it may look like the same problem, it’s always a different problem that requires a slightly different solution.

Q: What’s your coffee order, and where’s the best place to get that coffee from in Toronto?

A: A White Laotian Caramelized Coffee with 1 espresso, 2 milk, 1 sugar from Mos-Mos (specifically the one in Commerce Court).

Q: Outside of work, how are you involved in the tech community?

A: I’m very involved in FIRST Robotics to this day. In my opinion, volunteering with FRC is the most valuable thing that I can give back to the tech community because of how much it’s helped me and how much I see it helping the next generation. I spend most of my vacation time in March and April helping out at various competitions, and really enjoy volunteering my time at such an impactful organization.

About DevCycle:

DevCycle is the leading feature management platform trusted by companies of all sizes to improve their software development process and ship features faster with confidence. DevCycle offers feature flags, A/B testing, and integrations with popular development tools like GitHub, Jira, and Slack. Sign up for your free DevCycle account today.

Want to be featured in our next Developer Spotlight? Fill out this form!

Dogfooding DevCycle with DevCycle

Andrew MacLean — Tue, 28 Mar 2023 17:53:33 +0000

What is "dogfooding" and how can it improve your software?

What is “dogfooding”?

Dogfooding, also known as eating your own dog food, is the practice of using your own product or software to gain a better understanding of its features, user experience, and potential issues. Some of the key benefits of dogfooding include:

Identifying issues early on:

‍When you use your own software, you can identify bugs or issues that may not be apparent during development or testing. This allows you to fix them early on, before they become more significant problems.

Improving user experience:

By using your software regularly, you can gain a better understanding of how users will interact with it. This can help you make adjustments to the user interface or user experience to make it more intuitive and enjoyable to use.

Encouraging innovation:

When you use your own software, you may find new and innovative ways to improve it. This can lead to new features or enhancements that make your product more valuable to your customers.

Demonstrating confidence in your product:

Dogfooding your software sends a clear message to your customers that you have confidence in your product. It shows that you believe in what you've created and are willing to use it yourself.

Our beginning ✨

When we began building DevCycle, we decided from the get-go that we would also use DevCycle’s feature flags to release features within our own platform. As soon as we had a functional SDK, we started using it in the development of our dashboard. Naturally, integrating an unpolished product came with challenges, but by blocking our own workflow we were forced to fix bugs and improve the user experience quickly. In the beginning, dogfooding helped us identify pain points, unhandled edge cases, and ultimately be the first real users of our product.

Learning along the way 🛠️

Our dogfooding journey didn’t end after we launched DevCycle. In fact, to this day, we continue to expand the usage of our own platform to find out what’s working and what’s not. Here are a few things we’ve learned about our platform along the way:

We weren't accounting for high volume.

‍While developing a new tool, it can be easy to fall into the trap of only testing with new projects and sample applications, and think everything is working as expected. In the spirit of dogfooding, we set out to integrate DevCycle into our existing Taplytics codebase, and quickly realized that our methodology for tracking events wasn’t able to handle our own high traffic. By being our own first “high volume user” we had the time and flexibility to rethink our event aggregation before it was in the hands of real users.

Flag often, and flag granularly.

DevCycle's feature flags have played a critical role in helping us achieve CI/CD, deploy faster, and ship with confidence. We now use them for every new feature release, allowing us to rollout features gradually and test in production.

One thing that differentiates DevCycle from other feature flagging platforms is the ability to group multiple variables within a single feature. In practice, this gives us the ability to independently toggle aspects of a feature, saving us from fully disabling a feature when a deployment doesn’t go as planned. Being able to flag on this granular level allows us to release features in stages as development is completed and speeds up our overall release process.

There’s always room for improvement.

By using our platform day-to-day, we get to experience firsthand which areas can be improved — both within our own tool and within the industry. Many of our integrations, such as our GitHub actions, CLI, or Terraform Provider, were conceptualized because developers on our team saw a need for them, and found a way to improve our own development cycle. As regular users of DevCycle, we are enabling innovation within our team, platform, and the entire feature management industry.

Eat your own dog food

Dogfooding will continue to be an essential part of how we work at DevCycle. We aim to build tools that make developer’s lives easier and tools that developers are excited to use, and doing so starts with us. Being able to use and improve the tools we build translates into a genuine excitement to share them with the rest of the developer community.

Best Feature Management Software Comparison Guide 2022

Andrew MacLean — Mon, 27 Mar 2023 03:42:56 +0000

With feature flag management, dev teams can push releases with confidence, get more done, and improve the user experience. Find the best feature management software for you with this extensive guide.

Feature management systems are incredibly useful for development teams. With feature management, dev teams can push releases with confidence, get more done, and improve the user experience. Feature management makes it easy to toggle features on and off, switch users over to the new version of a software or an app, and fix bugs and issues without interrupting service.

Feature management is one of the most powerful tools that a dev team can have, but which tools are right for your team? There are a lot of options out there, so it's crucial to pick one that suits your team and seamlessly integrates with your processes.

Below, we've compiled the best feature management software available in 2022. Scroll on to learn more.

What Is Feature Flag Management?

Feature management allows dev teams to more precisely manage the rollout and rollback of features. Most management tools will also give you the ability to toggle features, meaning you can decide whether a feature is live in your app or software. Feature management also allows you to conduct A/B testing and customer experience personalization by rolling out certain features to one group and tracking analytics to see how they react.

In short, feature flags let devs deploy faster and more often while also making releases easier and less stressful. This makes both dev teams and users happy while increasing your business's ROI.

Choosing the Right Feature Flag Tools

Again, not every feature flag tool will be the perfect fit for every team. To choose the right feature flagging tool for your business, consider your budget and the features you need out of feature management software. The following are tools we recommend looking into.

DevCycle

When you're looking for the best feature flag tool available, you should choose DevCycle. DevCycle offers you everything you need for robust feature management, feature flagging, and A/B testing.

DevCycle is designed for modern dev teams to deploy their releases faster, reduce risk and release stress, and maximize ROI. Using DevCycle, your dev teams will be able to deploy more products, features, and updates than ever. The intuitive DevCycle dashboard is designed so everyone on your team can easily understand the reports and analytics, making the most of the rollout data you get from your feature releases.

DevCycle is easily scalable, making it perfect for dev teams and businesses of any size. DevCycle also has full SDK coverage, customized workflows, and instant code changes. The feature flag lifecycle tools also allow you to track flags at every stage in the development cycle. There are even a number of different types of feature flags, giving you more precise and useful feature management.

Here are some of the tools you get when you use DevCycle

Feature flagging and toggling tools
Kill switch for errors and features with issues
Easy-to-use dashboard
Multi-environment feature flag support
User targeting and segmentation
Feature A/B testing
In-depth analytics and reporting
Automated feature flagging tools

Who is DevCycle made for: Product engineering and software development teams

Pricing

Starter tier - FREE FOREVER
Enterprise tier - Custom Pricing, contact for details

Learn More About DevCycle and Why It's the Best Feature Flag and Feature Management Tool

Ready to get the most out of your page or apps by using our feature management software? Let DevCycle get you started. We make it easy to create an account and get started right away. We also have flexible pricing options that will work for any business.

Split.io

The Split.io platform is a feature management tool that focuses on measuring data and analyzing the effect of your features. With data-driven insights, you can determine which features are best and which need further optimization. This makes it easier for teams to make rollout and rollback decisions.

Here are some features you can expect when you use Split.io

Issue tracking for quick response
Kill switch for features with issues
Changing features without changing code
Analytics and metrics on your features
Audit logs to track your feature implementations and rollbacks

Who is Split.io made for: Development and engineering teams

Pricing

Up to ten seats free
Request quote for higher tiers

‍

Optimizely

Although Optimizely isn't primarily a feature flag management tool, it does have robust integrated feature management tools for dev teams to take advantage of. When you use the Optimizely full-stack software, you get feature management for testing features without implementing code. You can also toggle features and segment them by user groups, allowing you to A/B test your features. Although Optimizely isn't feature-management specific, it might be useful if you already have the software for other purposes.

Here are some features you can expect when using Optimizely

Intuitive dashboard for all of your feature flags
Customer feedback for your features
Feature flags for different pricing tiers
Tools for marketing teams

Who is Optimizely made for: Content marketing and optimization teams

Pricing

By request

‍

Switchover

Switchover is a software as a service feature flag solution that lets you toggle flags with just a click. You can toggle your features, use a kill switch to deactivate features that are experiencing errors, target different groups with feature A/B testing, and more.

Here are some of the features you can expect when you use Switchover

Percentual rollout to test features on smaller groups
Toggle for features and kill switch
User targeting to enable features for specific users
Free key/value pair support

Who is Switchover made for: Software development and operations teams

Pricing

Free tier for small businesses
Starter tier - 39 euros per month
Professional tier - 89 euros per month
Enterprise tier - 199 euros per month

‍

Flagship

Flagship is a feature flagging platform that allows teams to separate code deployments and reduce the risks of new releases. Using Flagship.io, you can have more fine-tuned control of your releases. You can also A/B test your feature variations with different groups, enabling product teams to roll out new features.

Here are some features you can expect when you use Flagship

Toggling features on and off remotely
Gradual and automatic feature rollout
User segmentation
Feature A/B testing

Who is Flagship made for: Developer teams

Pricing

Premium tier - $175 per month
Enterprise tier - custom quote

‍

Taplytics

Taplytics is a robust feature management tool that can be used across multiple platforms. Taplytics specializes primarily in A/B testing for your features with a simple and intuitive user interface. Using feature branches means that features can be tested and released and easily flipped off if things don't work out the way they should. Taplytics also allows you to release your features to smaller groups before doing a wide-scale rollout.

Here are some of the features you can expect when you use Taplytics

Flexible and customizable feature deployment
Gradual rollout options
A/B testing without the need for code
Audience segmentation
Analytics and data for feature impact

Who is Taplytics made for: Product, engineering, and marketing teams

Pricing

Custom pricing

‍

VWO

VWO is an A/B testing platform that includes tools for feature flag management. With the VWO full-stack, you'll get access to tools for toggling any product feature at will. VWO is easy to integrate thanks to its SDKs for all major programming languages and platforms. Audience segmentation and advanced reporting tools show you feature impact and help you optimize your rollouts.

Here are some features you can expect when you use VWO

Gradual rollout to small audiences
Multi-platform testing and toggles
Goal tracking and reporting
Deployment scheduling

Who is VWO made for: Marketing and UX optimization teams

Pricing

Request quote

‍

Unleash

Unleash is an open-source feature management tool that is built to integrate into any of your development team's workflows and processes. They feature simple tools for turning features on and off without redeployment.

Here are some features you can expect when you use Unleash

Gradual rollouts to smaller user bases
Measuring tools for feature performance
User-targeting features
Open-source

Who is Unleash made for: Software development teams

Pricing

Open-source and self-hosted tier - Free
Pro tier - $80 per month
Enterprise tier - custom pricing

‍

Statsig

Statsig is an experimentation platform that includes feature management tools for feature flagging, measurement of the impact of each feature deployment, and has reporting tools for data-driven decision making. Using Statsig, your teams can deploy more often.

Here are some features you can expect when you use Statsig

Controlled feature rollouts
Feature gates for front-end and back-end applications
Automatic A/B tests for each feature
Tools for easy collaboration

Who is Statsig made for: Product development teams

Pricing

Developer tier - free up to 5 million monthly events
Pro tier - $0.03 per 1,000 events
Enterprise tier - custom pricing

‍

CloudBees

CloudBees is a feature management platform that allows you to toggle features by user groups. With CloudBees user testing tools, you can easily toggle tools and analyze how features are working for different customers. CloudBees also enables collaboration and gives you simple permissions management to decide who can access the dashboards for different projects.

Here are some features you can expect from CloudBees

Split testing for your feature releases
Kill switch for features and feature toggle
Gradual rollout for user segments
Feedback tools to learn from customers
Config files for devs instead of dashboards

Who is CloudBees made for: Software development teams

Pricing

Starter - Free for one user
Team tier - custom pricing
Enterprise tier - custom pricing

‍

Apptimize

Apptimize is a feature release management and A/B testing tool that focuses primarily on mobile user experiences. Using Apptimize, you can iterate on your mobile features and make better apps for your users with shorter release schedules. Apptimize SDKs for all popular languages and an intuitive user interface for ease of use.

Here are some features you can expect when you use Apptimize

Gradual feature rollout and easy rollback; no coding required
Targeted user messaging
Cross-platform capabilities

Who is Apptimize made for: Product development and optimization teams

Pricing

Standard tier - free
Advanced tier - custom pricing
Enterprise tier - custom pricing

‍

Molasses

Molasses offers a suite of feature flag and A/B testing tools for faster deployment with fewer errors. Molasses can scale from small to large teams and has support for a number of programming languages and frameworks. Audit logging and Slack integrations will ensure your team stays up to date on what's been done and what still needs doing.

Here are some features you can expect when you use Molasses

Feature toggling; no code needed
SDKs for a number of programming languages
A/B testing for features
Audit logs to keep track of things

Who is Molasses made for: Software development teams

Pricing

Canoe tier - free for solo developers and very small teams
Clipper tier - $50 per month
Frigate tier - $200 per month

‍

Harness Feature Flags

The Harness software delivery platform includes a module known as Harness Feature Flags that includes robust feature management tools for your dev tools. The Harness Feature Flags module, made specifically for developers.

Here are some features you can expect when you use the Harness Feature Flags module

Feature flag process standardization tools, such as feature release templates
Integrations with a number of workflow tools, like Slack
Governance features including audit logs and RBAC
Seamless integration into dev team processes

Who is Harness Feature Flags made for: Software development teams

Pricing

Free tier
Team tier - $100 per month, per service
Enterprise tier - custom pricing

‍

ConfigCat

ConfigCat is a feature flag service that supports cross-platform feature management for mobile, desktop, front-end, and back-end rollouts. ConfigCat is intended for team smaller team sizes. With this hosted feature flag service, you should be able to decouple feature releases from your code deployment.

Here are some features you can expect when you use ConfigCat

User segmentation and targeting
Feature toggling, even after code is deployed
Open-source SDKs
Easy integrations with various apps and platforms

Who is ConfigCat made for: Software development teams

Pricing

Free tier
Pro tier - $99 per month
Smart tier - $299 per month
Enterprise tier - $849 per month
Dedicated tier - $4,499 per month

‍

Flagsmith

Flagsmith is a service for feature flags and remote config. Flagsmith allows you to manage feature flags across all of your applications, toggling features for different users and environments. Flagsmith also allows you to deploy your features to your private cloud or run it on-premises.

Here are some features you get when you use Flagsmith

A/B testing for features
Feature toggling and segmentation
Remote config for altering applications in real-time
Functional and visual changes with a few clicks

Who is Flagsmith made for: Software development teams

Pricing

Free tier
Start-up tier - $45 per month
Scale-up tier - $200 per month
Enterprise tier - custom pricing

‍

Firebase

Firebase offers several products and solutions for app development, release, and user engagement. They bill themselves as solutions that can help at every step of an app's journey. Firebase also offers extensions for automating common tasks and integrations with various tools like Jira, Slack, and more.

Here are some features you can expect when you use Firebase

Build tools for accelerating app development and managing backends
App release tools for monitoring app performance
Engagement tools for A/B testing and user analytics

Who is Firebase made for: App development teams

Pricing

Spark tier - Free
Blaze tier - Pricing based on usage, pay-as-you-go model

‍

Growthbook

Growthbook is an open-source platform for app deployment. It features A/B testing and feature flagging tools. Growthbook also provides in-depth analytics about product launches and full-stack experimentation. GrowthBook also supports all major SQL data sources.

Here are some features you can expect when you use Growthbook

Open source and self-hosted tools
Feature flagging and analytics
A/B testing
Wide variety of SDKs
Experimentation analysis automations

Who is Growthbook made for: Engineering, data, and product teams

Pricing

Open-source and self-hosted - free
Cloud tier - first 5 seats free, $20 per seat per month after
Enterprise - custom pricing

‍

AWS Evidently

AWS Evidently is a part of the suite of Amazon Web Services offered to developers. This tool is focused on feature flags and A/B testing. This is a fairly standard feature flagging and A/B testing tool, but it integrates well into the rest of Amazon's developer tool ecosystem.

Here are some features you can expect when you use AWS Evidently

Feature flagging
A/B testing
Easy integration with AWS suite of tools and solutions

Who is AWS Evidently made for: Software development teams

Pricing

Pricing is based on usage

LaunchDarkly

LaunchDarkly is a well-known provider of feature flags as a service. LaunchDarkly is made to integrate into your current dev team processes and comes with tools for collaboration amongst team members. You can also segment your apps into A/B groups and toggle your features as needed on your live apps and software.

Here are some features you can expect when you use LaunchDarkly

Software development kits (SDKs) for a variety of programming languages
App deployment before full release
Running canary releases without having to redirect traffic
Easy integration with other tools and platforms

Who is LaunchDarkly made for: All developer and product delivery teams.

Pricing

Starter tier - $8.33 per seat per month
Pro tier - $16.67 per seat per month
Enterprise tier - contact for quote

‍

Bugsnag

Bugsnag is a stability and error monitoring platform. Bugsnag is built to give you insights into your features, provide you with data to make decisions on new features, and help you learn which bugs need fixing. It is built for monitoring app health on mobile, web, and server-side applications. Bugsnag is focused on helping dev teams make data-driven decisions about the features they create and the bugs and errors they address.

Here are some features you can expect when you use Bugsnag

App stability data and monitoring
Error monitoring and diagnostics
Data-driven insights on app health

Who is Bugsnag made for: Software engineering teams

Pricing

Lite tier - free for one seat, up to $500 for up to 50 seats
Standard tier - $59 per month for 5 seats, up to $999 for 50 seats
Enterprise tier - custom pricing

Transitioning from Monthly Releases to Continuous Deployment

Andrew MacLean — Wed, 22 Mar 2023 19:27:36 +0000

Here's everything you need to know about transitioning to Continuous Deployment: How to achieve it, the tools and processes we recommend, and the benefits.

Transitioning to Continuous Deployment

If you’re reading this, you’re probably thinking of making the transition to Continuous Deployment (CD). Or perhaps you’ve made the transition, but you still don’t feel as if you’re using your CD pipeline to its fullest potential.

Transitioning from monthly (or semi-monthly… or yearly 😵‍💫) releases to Continuous Deployment is a rewarding shift that will pay dividends for your entire organization. But, as with any new software development process you adopt, there are concrete steps that you’ll have to take to achieve a proper and fully functioning CD pipeline.

We’re going to walk you through those steps so that your team can adopt CD, regardless of how often you deploy code right now. Then, we’re going to explain how we made the switch to CD here at DevCycle, and the benefits that we’ve seen firsthand from doing so.

What is Continuous Deployment?

Before we get into how to achieve Continuous Deployment, we need to understand what Continuous Deployment is, and where it fits into the entire Continuous Integration/Continuous Delivery/Continuous Deployment workflow.

All CI/CD pipelines have to start with Continuous Integration (CI). CI is the process of building, checking and running automated tests that your code has to pass through to be merged to the main branch.

From there, we move onto Continuous Delivery, which is the process of ensuring that your code in main is always in a deployable state so that you can deploy it whenever you want to. Code is automatically deployed to a testing environment in this stage, but is not deployed to end users until you manually hit the “deploy button”.

The final step is Continuous Deployment. Continuous Deployment is the process of automatically deploying code to your end users if it has passed all tests and stages to production. When we talk about transitioning to CD in this article, we’re talking about Continuous Deployment. This is the ultimate end goal for most organizations looking to release code multiple times per day.

At DevCycle, we like to think of CI/CD as the process of eliminating the ceremony of releasing code. Gone are the days of massive, end of month releases with large change footprints. With CD, small releases and deployments happen so often (ideally multiple times per day) that they become a part of the fabric of your company.

How to Achieve Continuous Deployment

Make it a gradual transition.

When talking to a few of our engineering leaders here at DevCycle, they all agreed that your transition to CI/CD should be a gradual one. (So, please don’t expect to continuously deploy 3 new features on day 2 of adopting CI/CD – that will end very, very poorly.)

We suggest you start with smaller changes, and smaller chunks of work. Instead of trying to go from releasing code three times per year to multiple times per day, set a goal for yourself to release code every 2 weeks, and then move to weekly, then daily, and–eventually–you’ll be releasing code multiple times per day.

Aim for Continuous Delivery first, then move towards Continuous Deployment.

Our other suggestion is to move closer to Continuous Delivery before Continuous Deployment. Of course, Continuous Deployment is the end goal, but Continuous Delivery is a bit easier to establish (and it has to be well established in order for Continuous Deployment to happen, anyways.)

Recall above that Continuous Delivery is the process of ensuring that your code in main is always in a deployable state – i.e. you can deploy whenever you want to deploy, but it will not be automatically deployed. From here, you will still have to manually hit "deploy" to release the code to end users. We recommend aiming for Continuous Delivery before Continuous Deployment for a few reasons.

First, moving right to Continuous Deployment is a large jump for teams that are used to manual releases and being able to manually review their code before it gets released to their users. Continuous Delivery is an easier adjustment as it gives you the chance to double check everything before it’s released to your end users.

Additionally, becoming comfortable with Continuous Delivery before Continuous Deployment gives you the chance to really validate and trust your tests. When you set up Continuous Deployment, your end users see any and all code that has passed your tests, so you need to be sure your tests are solid (i.e that they’re not letting buggy code pass through and/or that the bugs that do pass through are not critical).

With Continuous Delivery, you have a chance to see how your code is performing and manually validate it after it’s been tested. If you notice a bunch of errors and bugs in your code in the production environment, that probably means something is off with your tests. Thus, starting with Continuous Delivery gives you the chance to validate and ensure that your tests are actually doing their job and not letting buggy code pass through before you move onto Continuous Deployment.

Start with simple, low-risk code changes.

Our last piece of advice is to start with simple changes and low-risk updates when adjusting to CI/CD. Admittedly, adjusting to CI/CD takes time, confidence, and buy-in from your entire organization. Automating your tests and deployments may feel scary at first – especially for those responsible for building the tests. Starting with small, low-risk code changes allows your team to adjust to the process and gain confidence in it before moving to larger feature releases.

Once you become comfortable with Continuous Integration and Continuous Delivery, Continuous Deployment awaits. Here are some practical steps you can take to set up a proper CI/CD pipeline (in even the oldest and largest legacy codebases):

Step 1: Set up your pipeline.

The obvious first step is setting up a CI pipeline. This requires building out your tests and setting up a pipeline that ensures your code can be merged once it has passed said tests. (See content on CI above.)

Step 2: Tests.

The second step is to have a set of tests (that you trust!) in place.

Once your code passes those automated tests with CD, it’s released. Thus, you need to ensure your tests are trustworthy enough that you don’t need to manually review your code after, because you won’t be manually hitting “deploy” once your code passes them.

Let it be known here that, to start out, your tests don’t have to be super complex because you’re not going to be using CD for complex changes at first. They simply have to be end-to-end tests that, at the very least, confirm your site and/or platform work how your team intends. For example, for DevCycle, these basic end-to-end tests would ensure that our users can access DevCycle, log in, and create a new feature.

Eventually–when you have a fully fledged out CI/CD pipeline and you’re using it for almost all deployments, regardless of size & impact–you’ll want more complex and comprehensive testing in place. But for today’s purpose of simply getting started with CI/CD, basic tests are all you need.

Step 3: ‍Set up centralized logging or error management.

This ensures that when an error does happen (i.e. when buggy code makes it past all of your automated tests and gets released to your end users), you’re able to track down where it came from, and quickly address it. We’re not at all suggesting this one to create a culture of blame. It’s simply a necessary step when you’re automating so much of your test and deployment process.

Additionally, the good thing about CI/CD is that you’re deploying smaller, incremental code changes multiple times per day as opposed to massive code changes with a large change footprint once a month. Thus, using an error management platform with CI/CD is a much simpler process since the releases are so small and it’s easier to find exactly where an issue is.

Step 4: ‍Use feature flags.

We’ve already mentioned that Continuous Deployment can be a large adjustment for teams who are used to manually reviewing everything.

Sure, automating your test and deployment process speeds everything up because you’re eliminating the need for human intervention, which means your developers can spend more time actually writing code. BUT automating your deployments and giving up manual intervention can still feel scary. Using feature flags alongside CI/CD is an added cushion – a safety net, if you will – that boosts your team’s confidence in automated deployments.

Feature flags allow developers to turn features on or off without requiring them to redeploy their code. They act as a safety net for any dev team using CI/CD, because they make it easy to turn a feature off that isn’t performing correctly. Thus, in the event that buggy code makes it past your automated tests and into your users’ hands, you can simply toggle the feature off and your users will revert back to the original functionality – all without needing to redeploy code or update your application.

Our Firsthand Experience with CI/CD

Our transition to CI/CD here at DevCycle was a bit unconventional: We adopted a CI/CD pipeline in an entirely new codebase when we launched DevCycle. Admittedly, starting fresh with CI/CD is probably easier than implementing CI/CD into an existing codebase since we were able to cherry pick all new tools and processes and write entirely new tests.

But, as we proved in this article, achieving Continuous Deployment in even the largest and oldest of legacy codebases is possible if you follow the steps outlined above. Our work to move our previous legacy codebase, Taplytics, towards CI/CD is proof. We implemented a CI/CD pipeline into Taplytics’ codebase after it had been around for a few years. With Taplytics, we were able to move from releasing code every few months to a Continuous Delivery pipeline that allowed us to release every week. This taught us a lot about what to test, how to speed up builds and how to automate deployments before building a fully functional Continuous Deployment pipeline within DevCycle.

The Benefits of Continuous Deployment

Increases deployment frequency, decreases cycle time.

Continuous Deployment has enabled us to get code to production in as little as 15 minutes. This is a massive increase in deployment frequency compared to the 3.5 month release cycle we had with Taplytics. We’re able to release and iterate faster, respond to user feedback in real time, and deploy code multiple times per day.

‍### Boosts developer productivity.

When your developers don’t have to manually test and deploy their code, they have a lot more time on their hands to actually write code. CD significantly de-burdens our developers from the QA process and deployments so that they can spend their time and energy actually building DevCycle.

Makes developers better at their job.

Automating our tests and deployments with CI/CD has required our developers to really think about the work they’re doing. They have to ask themselves “is this code well tested?” and “is it well thought out?” since they’re relying on the checks and balances system that they build themselves for automated testing.

Easier to debug.

Any release you put out with CD is small enough where it’s very easy to find bugs. It can take weeks to find a bug in big releases that have large change footprints. When you release code with CD and something goes wrong, you know which release the bug belongs to and mitigating the bug takes less time.

Less stress, more confidence.

And since we deploy smaller and incremental changes with CD, the stakes are much lower and our developers are rid of the “post-code release anxiety” they used to feel with monthly releases. Without big bang releases, we can ship with confidence knowing that (likely) none of our changes will impact or break our entire platform. And if there is a bug in code, we know that we can easily rollback the changes or toggle the functionality off with feature flags.

The Bottom Line

Transitioning to Continuous Deployment is a big shift that requires buy-in from your entire organization to make work. While it may take some time to adjust to and some trial and error to set up the pipeline, the adjustment period is worth it. Once your CD pipeline is up and running properly, you’ll be deploying more frequently and automating more than you ever thought possible. Visit our CI/CD resource page for more info, or set up your DevCycle account today at app.devcycle.com

Everything You Need to Know About Continuous Merge

Andrew MacLean — Tue, 14 Mar 2023 19:05:41 +0000

You’ve heard of Continuous Integration, Continuous Deployment, and Continuous Delivery, but have you heard of Continuous Merge?

What's the difference between CI/CD and Continuous Merge?

Continuous Merge is a step that enhances the CI/CD (Continuous Integration/Continuous Delivery) process, and is likely already a part of many existing CI/CD pipelines. But don't worry, we're not going to be calling it CI/CM/CD now.

Continuous Merge is a process where code changes are automatically merged into the main branch, also known as the trunk, when they pass an automated series of tests and other workflows such as static analysis. This eliminates the need for pull request reviews on low risk PRs, which leads to a reduced Cycle Time, more frequent deployments, and more time on your developers' hands to actually write code.

So, Continuous Merge is a process of automatically merging code changes into a mainline branch, while CI/CD is a process of automating the testing, building, and deployment of software.

‍What's wrong with CI/CD?

CI/CD undoubtedly improves development workflows, reduces the manual labor involved in testing and deploying code, and leads to an increased deployment frequency. But it's not a perfect process.

Even the most well-oiled and automated CI/CD pipelines can get blocked by the manual step of code review. Pull requests and code reviews on simple changes that take days, even weeks, can lead to delayed releases and merge conflicts. Oftentimes, lengthy reviews come down to the fact that developers are too overwhelmed to tackle PR's when they have their own code to write and features to complete.

Continuous Merge addresses this bottleneck in CI/CD pipelines by eliminating the need for manual PRs and code reviews on low risk PRs. With CM, code only needs to pass tests and builds in the CI pipeline before it is automatically merged to the main branch. Thus, no PR approvals or code reviews are necessary.

You might be thinking: "Is eliminating PR's *really *a good thing? It sounds a bit risky."

It's a valid point. But the good thing about Continuous Merge is that you can assign rules for which types of code changes get automatically merged after passing tests in the CI pipeline, and which should undergo a manual review.

For example, PRs might feel like an unnecessary waste of time for minor, low-risk code changes - such as docs, formatting, or tests. In these cases, Continuous Merge is a massive help. Instead of pulling one of your devs away from more important work, or waiting a day for a review of a low-risk code change, these changes can be merged after passing the automated tests in your CI pipeline. This drastically reduces your cycle time and allows your team to deploy these incremental, low-risk changes more frequently.

Other times, manual PRs feel a lot more necessary and important. For example, if you're worried about security issues for a big release, you might ask for 2-3 reviewers and you want to be sure that code is reviewed by the right people. For these, you might want to opt out of Continuous Merge and undergo a manual review. Even if you opt out of Continuous Merge for these larger, riskier releases, you'd still be improving your cycle time with CM since the smaller, less risky releases are being tested and merged manually. You're also giving your developers a lot of time back by only asking them for manual assistance on PRs that are absolutely necessary.

Ultimately, getting the most out of Continuous Merge is all about knowing which code changes your team is comfortable with automatically testing and merging, and which need to be manually reviewed for maximum safety.

Feature flags and Continuous Merge

Continuous Merge is a powerful process in and of itself, but when paired when feature flags, is a true force to be reckoned with. Feature flags are an added sense of security when used alongside Continuous Integration, Merge, and Delivery. For example, if a PR only included changes within a feature flag and that flag happened to be disabled, there could be a set of rules that indicate that it could be merged automatically. It could even be marked for review after it had been merged. This allows code changes to be deployed without affecting the user experience, while also allowing developers to test the changes in a real-world environment.

At DevCycle, we like to say that feature flags are like a safety net for developers. This is especially true when leaning on Continuous Merge to eliminate code reviews and ship code faster. As mentioned above, assigning rules to ensure that only smaller, less risky code changes are manually tested and merged is one measure you can take to reduce the risk of bugs and other performance issues. Should an issue arise with code that was tested and merged automatically, though, feature flags allow developers to simply kill the feature or rollback any changes instantly.

‍How DevCycle uses Continuous Merge

At DevCycle we've adopted a tool called gitStream to enable Continuous Merge. We're still new to the concept ourselves, so we're taking it slow with our CM criteria, but we've already seen improvements to our cycle time by enabling it in our most active repos. We plan on building up a larger and more comprehensive set of CM rules over time to really improve our flow. We've implemented CM for merges that gitStream says are formatting, documentation updates, changes to tests and are from dependabot.

To set up gitStream in GitHub, visit: https://docs.gitstream.cm/github-installation/

Wrapping up

The truth is, the more processes you can automate in your workflow, the less frequently you'll be pulling your developers away from actually writing code and building your core product. DevCycle's feature flags enable teams to automate their tests, merges and deployments for a faster cycle time and increased deployment speed. Chat with one of our product specialists for more information on feature flags and Continuous Merge, or get started with DevCycle on your own today.

Developer Spotlight: Laura Warr

Andrew MacLean — Wed, 15 Feb 2023 20:45:54 +0000

February's Developer Spotlight features DevCycle's very own Staff Software Engineer, Laura Warr!

Q: Where did you go to school/what is your background in engineering?

A: My background in engineering is a bit unconventional; I have my Bachelor's in Math from the University of Waterloo, where I studied computer science fundamentals and computational math, but I wasn't on a direct path to work in software right away.

After graduating, I was interested in UX design, so I took a one year program to become more familiar with user experience testing and web technologies. The work that I did there really reinforced my interest in software, specifically in server-side development. After my co-ops and schooling, I worked in a variety of industries ranging from social media analytics, to dev tooling for iOT systems, FinTech, and even warehouse management for sustainable grocery delivery. One of the things I find really exciting about building software is that you can apply the same skill set to solve problems in almost any industry.

Q: What's your favourite thing you've ever built or worked on as an engineer?

A: It's hard to come up with one answer for this, but some of the stuff we're working on at DevCycle is pretty cool. I've especially enjoyed working on some of the code analysis that we've integrated into our GitHub actions and CLI. Our first approach to this was parsing and analyzing the text, and then we moved to using ASTs (Abstract Syntax Trees), but both approaches have presented some pretty interesting problems. Not to mention it's really cool to be building a tool that can refactor my own code!

Q: What is one tool in your current stack that you could not live without?

A: Either having a CI/CD pipeline or using a typed language. We made the switch to both of these when we launched DevCycle, and it has made deploying code so much less painful. Plus, type safety is game changing!

Q: Which programming language are you most familiar with, and which do you prefer?

A: I use Typescript day to day, so it's what I'm most comfortable with.

Q: If you could give any engineering related advice to your younger self, what would it be?

A: Keep maintainability and scalability in mind. Think about the person who will be working on your code next. And write tests --- they're there to help you, and they make it easier to develop quickly and confidently, even if they seem like a chore at first.

Q: Where do you go to stay up-to-date on all things engineering?

A: For the most part, it's just browsing blog articles. I learn a lot from my peers as well, and Reddit can have some interesting resources (although I take Reddit with a grain of salt).

Q: What's the largest roadblock or challenge you've ever had to navigate in tech?

A: Working with a large legacy code base that's lacking test coverage. When developers can't make changes confidently and have to rely heavily on manual testing, it greatly slows down the development process and sours the developer experience. This is something that we dealt with in the Taplytics codebase prior to launching DevCycle. By including test coverage early and using feature flags to release new features, we've minimized risk and made the release process painless.

Q: What's your least favourite thing about being an engineer?

A: Having to be at a computer all day. I like a lot of aspects of development, but I'm an active person and enjoy being outside so being desk-ridden is the biggest downside.

Q: What's your favourite part about your job/being an engineer?

A: Without a question, it's problem solving. Problem solving is central to a lot of my hobbies --- I love being faced with an open-ended problem and working with the tools at my disposal to find a solution. Similar to balancing a math equation or figuring out the beta to a bouldering problem, there's a very satisfying feeling that comes with designing a clean, well-tested piece of software.

Q: What's your coffee order, and where's the best place to get that coffee from?

A: I usually just go with black coffee from home!

Q: What's your favourite music type or band, and where do you listen to your music?

A: I'm probably the odd one out on this, but I don't listen while I'm working. Around the house I mostly use Spotify, and Capital Cities seems to be my go-to right now.

Want to be featured in our next Developer Spotlight? Fill out this form!

Developer Spotlight: François-Xavier Beckers

Andrew MacLean — Thu, 02 Feb 2023 19:31:59 +0000

This month's Developer Spotlight blog features François-Xavier Beckers, CTO at Clinical.ly.

Q: Where did you go to school/what is your background in engineering?

A: As far as software engineering goes, I’m mostly self-taught.

When I first started learning to code, I was 12 or 13 years old, and I was doing everything on my graphing calculator. Back then I thought that I wanted to go into Special Effects in the film industry and was using Adobe Flash to make animated movies. The fact that flash was at the crossroads between graphics and programming exposed me further to software. I loved the creativity of film, but at that time my best friend and I were trying to make more elaborate movies that required more expensive equipment, tools and resources that we didn’t have access to. However, in software you didn’t need all of that. In software, the only limitation is your imagination. I devoted more and more of my time to software, which became my true passion.

I ended up getting a degree in Electronic Engineering from Southampton University.

Q: What’s your favourite thing you’ve ever built or worked on as an engineer?

A: While I was in my second year at University, Apple opened iOS to native apps. I built an app called iSoton, which was essentially an unofficial digital assistant for students at my university to help them better manage their student experience. It scraped class schedules from the student portal, showed you where your lectures were on the campus map, and downloaded everything for offline use which was important at the time. This was the first time I was able to build something that was utilized on a large scale. It was extremely exciting to see people using it on campus and benefiting from my app. A moment that had a big impact on me is when I was running super late to an exam and burst into the university convenience store to ask where a certain building was - the lady at the counter looked it up in iSoton.
‍
Q: What is one tool in your current stack that you could not live without?

A: I love the Git integration in VS Code and the fact that you can work/edit code from within the diff view.
‍
Q: Which programming language are you most familiar with, and which do you prefer?

A: My absolute favourite would be C#. However, right now I work more frequently with TypeScript.
‍
Q: If you could give any engineering related advice to your younger self, what would it be?

A: Don’t try to fit a square peg into a round hole; recognize when something isn’t working and seek alternative solutions as needed.

This would have been especially helpful when I was first learning development. I didn’t have access to a ton of tools or resources at this point (or so I thought), so I just leaned heavily on the same tools and approaches to do everything, rather than seeking out new ones.

For example: When I was younger, I built a moonlander game in pascal. I spent a couple of months trying to make my lunar module rotate because I was drawing it line by line. I could have written the game in a framework/language with a more sophisticated graphics API, and imported/rotated a graphic of the LM.

‍Q: Where do you go to stay up-to-do on all things engineering?

A: Medium always has good content. I actually splurged on Medium Premium recently.

It’s worth noting that, now that I’m on a smaller development team, I find the internet/developer platforms critical to keeping up with development news. Previously, when working on larger dev teams, osmosis was enough to stay-in-the-know.

Q: What’s the largest roadblock or challenge you’ve ever had to navigate in tech?

A: One of the biggest challenges I tried to overcome was in my endeavour of modernizing/standardizing a toolbar component that was used in applications all over my previous company’s intranet. A colleague of mine had written a nice AngularJS version and I was trying to distribute this component across our estate whilst simultaneously upgrading apps that were using the old one. The fact that the applications were written in a range of different technologies coupled with the fact that some of our users were running IE in compatibility mode made it a real nightmare to find a one size fits all solution that worked well across all applications and browsers. I had to compromise and create different variants of it for the different use cases in the end. As a developer this was frustrating because you don’t want to duplicate code and you want components to look completely consistent, but in this case, I had to follow the 80-20 rule.

Q: What’s your least favourite thing about being a developer?

A: The hardest thing is when a bug comes up and you have not even a single hunch of where it might be coming from or what kinds of ramifications it’s having on your users. You pretty much just have to start digging for it immediately and hope you find and recover it in short order. I find this part very stress-inducing.
‍
Q: What’s your favourite part about your job/being a developer?

A: I love the lasting productivity gains people achieve when they employ the systems I build. As a technologist, your impact scales indefinitely via the machines you create as their impact persists without requiring your continued involvement.

It's especially gratifying at Clinical.ly, as technology penetration in clinical research is relatively low. I've witnessed firsthand how access to our platform helped streamline operations, improve productivity, and accelerate drug development, thereby improving and saving lives!

Q: What’s your coffee order, and where’s the best place to get that coffee from?

A: My coffee order is just Espresso, and I usually get it from Starbucks! I have a theory that the places that make “good” espresso are actually tailored to be in a mixed drink.

Q: What's your favourite music type or band, and where do you listen to your music?

A: I listen to music on Spotify all the time. I listen to everything – not one genre really, but my top genre is probably Organic House.

About Clinical.ly:

Clinical.ly is a fast-growing, SaaS start-up providing differentiated technological solutions to the clinical trials industry. Our modern, intuitive platform provides tools for clinical research organizations to stay ahead of the evolving demands of sponsors and regulators.

About DevCycle

Want to be featured in our next Developer Spotlight blog? Fill out this form!

Understanding the Product Development Life Cycle Keeps Your Team on Track

Andrew MacLean — Thu, 02 Feb 2023 19:31:59 +0000

Understanding and using the product development life cycle helps teams execute more agile product development, which is increasingly important in an ever-changing economy. Teams can visualize their work, mapping it to different development stages along the way.

Every product and feature rollout starts with a seed of an idea. Ideas come from everywhere. It may be internal or external, analytically-driven, or creatively-fuelled.

So, how do you turn those ideas into full-fledged products for your customers? And how do you sift through all the ideas and prioritize for the most ROI and best customer experience?

Understanding and using the product development life cycle helps teams execute more agile product development, which is increasingly important in an ever-changing economy. Teams can visualize their work, mapping it to different development stages along the way. It makes it easier for product managers to guide the development process and increases visibility into how every individual's work comes together to create a product. And it helps teams prioritize for the greatest ROI.

You can look at the product development process as a cycle---a continuous, iterative process that you plan, build, and release for a product. The product development life cycle breaks the process into seven different stages.

1. Idea Generation

Idea generation is the first stage of the product development life cycle. This is where you develop your initial product concept. Some ideas may never see the light of day, while the most plausible ideas move into the next stage of the product development life cycle.

Make idea generation more than just an organized meeting or forum where people can share ideas. Create a culture of ideation and collaboration to keep coming up with new and innovative ideas. This includes transparency and regular knowledge-sharing, both about your company and the industry as a whole. You'll also need to set the team up with collaborative tools---things like Slack and video-conferencing software---to empower people to brainstorm with colleagues on their team and across other departments.

Inspiration and ideas come from everywhere:

Your employees. Create a way for staff on your team and in other departments to submit ideas---consider a Google Form so people can do it on their own time, and when ideas strike. Give them the option to remain anonymous should they choose. Hold regular brainstorms: both individual and in organized group settings.
Competition. It's always a good idea to see what your competitors are up to. Note new products and feature launches and share them with your team. This could spark ideas for your own offerings.
Market research. Market research encompasses a lot of things, from the state of the economy to consumer behaviour. Staying up to date on market trends will reveal opportunities for new product ideas.
Customer feedback. Your customers are one of the most important and valuable data sources at your disposal. At DevCycle, we're paving for the way for this sort of user-driven growth in the feature management space via our Feature Opt-In program. Feature Opt-In allows end users of your product to "opt-in" to different functionalities, and provide critical feedback to your team. This user-driven growth helps your team balance both business and user needs in product development.

2. Idea Screening

While the idea generation stage is all about coming up with as many ideas as possible, idea screening is where you narrow down the options to choose the best ones. This avoids wasted resources.

So, how do you know which ideas are best? According to a survey, 43% of teams prioritize the ideas that were most requested by their users---this is a simple, customer-first approach based on feature requests. The same survey showed that 88% of product managers solicit feedback before they build a product. You could also prioritize based on ROI potential or chronological order---or a combination of more than one.

However you decide to prioritize, share that with your team and allow them to screen ideas as well. Zappos, for example, empowers their whole team during the idea-screening stage of the product development life cycle by allowing each individual to prioritize their ideas and experiments independently. This has mitigated bottlenecks and created an environment where product teams aren't afraid to own and test ideas.

"The majority of our team can run experiments without even telling me," says Zappos' Head of Product, Andrew Nguyen. "They just need to execute and report on their experiments with a high level of integrity."

3. Concept Development and Testing

Now it's time to get into the nitty-gritty. Focusing on your best product idea(s), this stage of the product development life cycle is where you build out a "blueprint" for bringing it to life. Then you can test it for early feedback.

The best product development strategies incorporate ongoing testing. There are many ways you can test concepts. More than a third of product managers who responded to a survey say they candidly collect feedback, making it the most popular method. Others leverage user research groups (27.4%), analytics (20.4%), beta-testing programs (9.6%), and interviews (7%).

4. Business and Marketing Strategy Development

You've adjusted your detailed concept based on early feedback and are now ready to move onto the next stage: business development and marketing strategy. This is where you build a plan to bring the product idea to the masses (or your selected target group).

Take Drift, for example. They coined the phrase "conversational marketing" and used that as a key tenet in their marketing strategy and business plan. They had the idea, developed and validated the product concept, and promoted it through effective marketing, going so far as to write entire books on the subject. This primed their audience for their product and drove user engagement.

And it doesn't stop there. The product development life cycle is continuous, and Drift rolls out new products and features, namely their revenue acceleration platform, for which they've taken a similar content-driven marketing approach.

It's important to consider a cross-platform approach in your marketing strategy. Email marketing, push notifications, optimizing for mobile, and personalization are all key to effective marketing.

That's a lot of different pieces to put together. Incorporate marketing automation to set things on auto-pilot and free your team's time for more important tasks---and the next stage of the product development life cycle.

5. Product Development

Now your new product idea is really going to come to life. This is the stage that puts the "product development" in "product development life cycle." Use your tested and proven concepts, adjust according to feedback, and build your product based on your business and marketing strategy.

The product development stage includes things like branding and naming. You give new features their official name and put new products in a branded package that's cohesive with the rest of your offerings.

6. User Testing and Optimization

You might think your work is done when the product is complete, but that's just stage five of a seven-step product development life cycle. Now it's time to test and optimize the strategies you've built. This is your opportunity to drive user adoption rates and optimize the product experience.

7. Commercialization and Release

According to one Gartner survey, 45% of product launches are delayed at least one month. And one month in today's environment is a *long *time. Botched product releases negatively impact the customer experience and overall brand perception.

To mitigate these types of delays during your commercialization and release phase, build a release management plan. This serves as a guide to make it easier to execute phased rollouts. Phased rollouts break the release into smaller steps so it's easier to execute. A phased release with feature flags also prevents delays by rolling out changes slowly and making it easy to revert when needed.

Feature flags allow you to turn specific functionality on and off without requiring you to write additional code. They make it simple to dynamically change your code without needing full deployments to roll out the changes. You can more easily test features in production before you release them to the public, as well as controlling individual users' experiences and gaining insight into the effectiveness of your release.

Bring the Product Development Life Cycle Full Circle with Customer Insights

Understanding and using the seven stages of the product development life cycle keeps your team motivated and organized, and projects prioritized and smoothly executed. It helps create a culture of continuous ideation and experimentation so you can get the greatest ROI on new products and features. DevCycle offers a suite of tools that you can use at each stage to help you maximize efficiency and ROI. Create your account today!

Your Guide to Proper Feature Flagging Hygiene

Andrew MacLean — Wed, 01 Feb 2023 18:49:24 +0000

Here are a few feature flagging hygiene best practices to ensure your code remains clean, regardless of how many flags you have in your codebase at once.

What are feature flags?

Feature flags, also known as feature toggles, are a software development technique used to enable or disable functionality without making changes to code. They allow developers to test new features without making them available to all users, or to enable or disable specific features for certain user groups. They can also be used to enable or disable certain areas of code in order to reduce risk during a software release.

Ease of use & implementation

Feature flags are easy to use and implement, especially when using a proper feature flagging solution (like DevCycle!) that makes it easy to set up flags and control how they are used. With DevCycle, you can easily control who sees your features and when, set up experiments to test different variations of your features, and track usage and performance.

While the benefits of feature flags are plentiful, some teams fear that using flags will add complexity to the codebase since they technically require additional code to set up and manage. However, there are feature flagging hygiene best practices that help ensure that your codebase remains clean, regardless of how many flags you have in your codebase at once. When you practice proper feature flagging hygiene, feature flags actually reduce technical debt and lead to a cleaner codebase.

Feature flagging hygiene

Feature flagging hygiene is the practice of regularly maintaining and cleaning up feature flags. This includes removing any flags that are no longer needed, disabling any flags that are not providing the desired value, and removing any configurations related to the flag.

Disabling and removing feature flags when they're no longer needed is the most important step in maintaining a clean codebase. But in order to know when a feature flag should be removed, we must first understand the entire lifecycle of a feature flag and what purpose the flag serves in each phase.

What is the lifecycle of a feature flag?

The first phase in a feature flag's lifecycle is the actual creation of the flag (this is usually done in the development phase). It is then tested in the staging phase, before being enabled and released in the production phase. During the production phase, the feature flag is monitored and tracked to evaluate its performance and usage.

Finally, the feature flag is removed or disabled when it is no longer needed, or when it is not providing the desired value. Feature flags should also be removed when a feature has been tested and is ready to be released to all users. And of course, a feature flag should always be removed if it is causing technical or performance issues.

When removing the flag from your code, you should also remove any tests or experiments associated with it, along with any configurations related to the flag, such as user groups or rules. Finally, you should review any metrics or analytics associated with the flag to ensure that your changes had the desired effect.

How should you remove a feature flag?

It's important to ensure that the code is not adversely affected by the removal. Thus, it's best to first disable the flag, then test the code to ensure that it still works as expected. Once you have verified that the code functions properly, you can then safely remove the flag and any associated tests or experiments.

Managing technical debt with feature flags

Feature flags are a tool intended to help teams increase deployment frequency and reduce release complexity. And they do just that -- especially when your team prioritizes proper feature flagging hygiene.

What's even better? Feature flags also help your team manage technical debt -- another software development practice that's key to maintaining a clean codebase and optimally running product.

Since feature flags allow developers to test new features without making them available to all users, they help reduce the risk of introducing bugs or other issues into the codebase. They also allow developers to make incremental changes that can be easily tracked and tested, rather than solely relying on massive, end-of-month feature releases that are often filled with bugs. Also, feature flags reduce the complexity and cost of maintaining or fixing code, since they allow teams to enable or disable certain areas of code at a time. Lastly, feature flags can be used to track usage and performance, which can help identify areas of the code that need to be improved or refactored.

Ultimately, feature flags are an effective way to increase deployment frequency and release more features without introducing codebase complexities. Get started today with DevCycle's feature flags today, and use this post as a feature flagging hygiene best practice guide!

Why The Digital Product Owner is The Most Important Person On Your Team

Andrew MacLean — Thu, 12 Jan 2023 17:28:45 +0000

Modern consumers interact with companies across a number of digital channels every day. Being able to provide a seamless experience at each touch point is vital to your success. But as these digital experiences become more complex, the need for a dedicated role to manage that experience increases. Enter the digital product owner.

A digital product owner (DPO), sometimes called a digital owner, is the person who manages every aspect of your company's digital experience. They work to streamline internal processes for your team, manage the tools required to complete these processes, and ensure that users have a consistent experience when interacting with your company online.

Managing the myriad interconnected processes and people that affect the digital experience is only going to get more complicated as your company grows. The DPO's goal is to align your team's digital strategy with your business goals.

Working across multiple teams in this way, digital owners share a lot of responsibilities with product managers---but with more focus on a specific aspect of the user's experience with your product. They make sure that users and your team get what they need at every step along the way.

1. Digital Product Owners Manage Your Technology Stack

Creating a winning digital experience is possible only when the tools in your tech stack work together seamlessly. From front-end web services to data warehouses to CI/CD pipelines, modern product teams use an incredible amount of technology every day --- which means there is potential for individual points of failure at any level.

A great DPO understands how all of your tools integrate with one another and uses that knowledge to make the experience of interacting with your technology stack as efficient as possible.

Example technology stack via Stack Overflow

Whenever your team has to develop a new feature or build a new product, your DPO provides valuable insights into the technology required to push projects across the finish line. Not only does this make it easier to define a clear product development plan, but it also cuts down on the overall work required to get it done. Instead of spending their time scoping out the best possible tools to use, your team can get started on active development as quickly as possible.

Your digital product owner will also review this technology stack regularly to identify possible improvements. If a particular tool no longer integrates into your stack effectively, or the price to do so becomes prohibitive, digital owners will find and vet an alternative.

This comprehensive knowledge of your technology stack is the key to creating better development experiences for your team.

2. Digital Product Owners Work to Understand User Behavior

A deep understanding of users' needs and behavior is at the core of any goodproduct strategy. Whenever you create a new product or feature, your team needs to anticipate user needs to build something that is truly valuable. Digital product owners share customer insights with product managers and collaborate to ensure that your team solves a real user problem while also making an impact on your business goals.

Digital owners use the tools and technology they manage to dig into customer data and pull out common traits and behaviors, and then they use this data to create experiments that test and validate their insights.

Those experiments help your team build more realistic user personas, which you can use to target prospects that share similar traits with your current customers. Let's say you're seeing decreasing engagement with your product's email-automation feature. Your digital owner would take a look at those customers who are no longer using the feature, as well as those who are, to identify the core differences. Then, they could take that info and create an experiment to tweak the experience of using that tool.

Using customer data, digital product owners can then target users who had issues with the tool in the past and let them know you've updated it with new functionality, such as adding a link to email automation in the top-level navigation, or simplifying the process of adding new emails to a campaign.

These kinds of tests require an in-depth understanding of each digital touch point a customer hits when using the tool as well. So your digital owner would have to work with other members of the team to gain as much insight as possible before getting started.

3. Digital Product Owners Provide Cross-Functional Support

Building a seamless digital experience requires input from points of contact across multiple teams, so digital owners need to work with many people with varying levels of seniority. Digital product owners facilitate processes across these teams and act as the conduit for information between each member. Providing this support makes it easier for every member of the team to focus on their day-to-day responsibilities.

Interacting with these different people daily means digital owners are comfortable speaking to engineers, marketers, product teams, and leadership. Whenever they need to share key insights, this level of comfort helps them frame important insights for each group individually.

Leadership teams, for example, would need to see the overall business impact of a given project, whereas marketing teams would want to understand the value add for customers and how to create messaging around it. Being able to provide this information based on their target audience makes your digital owner a vital component of your internal feedback loop.

Example of team feedback loop

Acting as the conduit for important information means DPOs are well-versed in ensuring clear, easy-to-understand communication across and within teams. They document conversations proactively and work to increase visibility into every aspect of the project. Working together with product managers, they're one of the key points of contact for your team.

Of course, having a tool in place that makes it easy to keep all internal teams and other key business stakeholders in the loop certainly helps. DevCycle's feature management dashboard was built with the DPO in mind. With an intuitive, easy to navigate UI and a global view dashboard that lets you easily keep track of all of your flags and projects at all times, DevCycle helps everyone stay in-the-know.

4. Digital Product Owners Manage the Team's Workflow

Digital product owners work with product managers and teams to prioritize the work required to complete any project. They understand everything it takes to build good products based on a deep knowledge of customer needs and can easily turn those insights into actionable tasks for the team. And they do all that while maintaining a high-level view of the product vision and strategy.

While the process for managing these projects will depend on the specific tools and methodologies you use, digital owners help create clear tasks and pipelines for your team to follow.

Example of Scrum board via Trello

In this example from Trello, the team uses the Scrum/Agile method to create a clear sense of the work required, the work that's completed, and the work that still needs to be done, each of which is tied to a specific objective defined for the project and your team.

When you understand how to align specific tasks with overarching product and business goals, it gives the team the visibility they need to move forward together. And this shared direction creates valuable context, which you can use to build products faster and more efficiently.

Great digital product owners are able to organize projects with this amount of granularity, while also switching to a 10,000-foot view of each project at times as well. This balance helps them adjust priorities as projects progress and proactively identify/solve for potential bottlenecks before they impact your release schedule. They understand your release management plan and use it to mitigate the risk of overlap or dependencies within your team.

5. Digital Product Owners Track Team Progress

Seeing an idea through from its conception to a feature release is a long and complicated process. Digital product owners work with product managers to keep track of your overall progress and report on it for the team. They have a clear set of objectives and key results (OKRs) to measure against, and a keen sense of how each stage of the product development process works together to create a winning digital experience.

Digital owners define these OKRs at the start of every project that affects the digital experience and focus on how any upcoming product or feature updates affect various touch points along the way.

Your digital product owner shares these OKRs with the team and reports on them as the project progresses. This maintains consistent visibility into the product vision and strategy and keeps everyone headed in the same direction. And increased visibility makes it easier for your team to execute on their respective tasks with confidence. It boosts engagement with the project as a whole and helps your team stay accountable for their work.

While digital owners concentrate solely on the online customer journey, this clarity ensures that any new feature update or product rollout is in line with what your customers expect from your digital experience. Basically, they make sure that everything you do adds value without making a negative impact on customer perception of your product.

The Digital Product Owner Is a Vital Part of Your Team

When so much of the customer experience is built on top of digital products, having a dedicated person to manage that experience is very important. Digital product owners are the key to building an online experience that's relevant for users while also making it easier for your team to achieve their goals.

The next time you're planning a release that impacts the online experience, define a digital product owner to work with your product managers and team to ensure that every release has a real positive impact.

Adopt the “10,000 Experiment Rule” like Netflix and Facebook

Andrew MacLean — Wed, 11 Jan 2023 21:34:15 +0000

Simmons' 10,000 experiment rule is pretty simple, and it's a principle that's been practiced by leaders and operators at companies like Facebook, Netflix, Google, and Amazon. It simply states that “deliberate experimentation is more important than deliberate practice in a rapidly changing world.”

If you've ever learned to play a sport or a musical instrument growing up, you've probably heard the phrase, "practice makes perfect." As kids, we were conditioned to think that the more time we devoted to learning a craft, the closer we'd get to perfecting our skills.

Today, that may no longer be true, especially in rapidly changing fields such as technology and business. Rather than spending 10,000 hours learning how to become a world-class performer, Empact founder Michael Simmons recommends that you follow what he calls the "10,000 experiment rule."

Simmons' 10,000 experiment rule is pretty simple, and it's a principle that's been practiced by leaders and operators at companies like Facebook, Netflix, Google, and Amazon. It simply states that "deliberate experimentation is more important than deliberate practice in a rapidly changing world."

Whether you're trying to build the next Facebook, or create a mobile travel app, the principles that govern how products look, feel, and behave today will change tomorrow. Since Apple launched its App Store, we've seen endless experimentation applied to mobile applications, and we're seeing more to come, especially in augmented and virtual reality.

This fast-moving world can feel daunting for product and engineering teams looking to build impactful products, but there's a simple rule to navigating it. Avoid making large, massive bets on one or two big projects/features. Instead, build the habit of running smaller experiments at a faster cadence.

Source: Michael Simmons

Rather than betting the company on a major app re-design, start by running smaller tests on your navigation and onboarding flow. These won't necessarily immediately fix your retention or engagement problems. But week over week, making small, incremental improvements of between 2-5%, can translate into a massive increase to your bottom line. That's because small wins compound into big ones over time.

Leading companies today break new ground by experimenting quickly and often, rather than trying to slowly gain expertise around a specific industry. Companies like Google, Amazon, Netflix, and Facebook, run thousands of experiments each year.

Rapid Release and Experimentation at Facebook

If you've ever looked closely at the Facebook app on your phone and compared it to a friend's, you may have noticed a difference between the apps. That's a feature, not a bug.

While startups are often told to "move fast and break things", many companies---Facebook included---don't have the luxury of breaking things. To scale to billions of users, Facebook has to rapidly experiment and innovate on product. At the same time, with so many people relying on Facebook each day, the company can't run the risk of breaking its app.

As Facebook VP Andrew Bosworth says,

The most obvious approach might be to imagine the future you want and build it. Unfortunately, that doesn't work that well because technology co-evolves with people. It's a cycle---technology pushes people to move forward and then people move past technology and it has to catch up.

When Facebook runs experiments, it will often test new ideas and features through a feature rollout where it's tested upon only a small fraction of users. In some cases, Facebook will scope this even more specifically by deploying only to people within a specific market or country. This gives Facebook a granular level of control over how it's able to test new features, get feedback, and improve engagement and usage of the app. Feature management solutions like DevCycle enable gradual feature rollouts so that you can release features to a smaller subset of users and validate their functionality before sharing them with your entire user base.

This graph shows the deployment of an experiment over the course of a week. The light green bar shows the total number of users in the experiment, while the dark green bar shows the number of users the experiment impacts. Each day, Facebook rolls the experiment out to larger number of users.

Source: Facebook

Here are a couple of ways that Facebook has applied this approach to rapid development and experimentation over the years:

Disappearing messages and Stories: Facebook-owned Instagram famously copied Snapchat's "Stories" feature, growing to 250M daily-active users. What's less well-known is the fact that this was the culmination of a series of failed experiments that Facebook had launched around disappearing messages and quietly killed.
The "Explore" Feed": Facebook tested a secondary "Explore" Feed to its primary News Feed in six countries, to surface content to users for pages they hadn't explored with. Early test results show that the new feature resulted in a60-80% engagement rate. Rather than experience that drop in engagement across the app globally, Facebook was able to limit the experiment by testing it on a smaller segment of users first.

The moral of the story is that adopting the 10,000 experiments rule isn't about recklessly throwing ideas at the wall to see what sticks. It's about working within the constraints and providing yourself with the ability to *safely *run a lot of experiments and learn at scale.

Cross-Platform A/B Testing with Netflix

Like Facebook, Netflix deals with many of the same issues around rapid experimentation and development. Netflix has over 109 million subscribers worldwide, and one study shows that it's single-handedly responsible for 35% of internet traffic in North America.

Building around experimentation is what has helped Netflix build such a sticky product. Netflix researchers estimate that if a typical user doesn't find something to watch in the app within 60-90 seconds, they run the risk of getting bored and moving onto something else. The company fanatically A/B tests everything--from the content that a user sees when they open the app, to loading speeds--in order to optimize their UI.

As one company blog post wrote: By following an empirical approach, we ensure that product changes are not driven by the most opinionated and vocal Netflix employees, but instead by actual data, allowing our members themselves to guide us toward the experiences they love.

To achieve this, one of the biggest challenges Netflix had to solve for was the fact that its users access the product across platforms, from their laptops, to mobile phones and gaming consoles. To make data-driven decisions, Netflix has to test continuously---but degrading the user experience with playback interruptions and slow buffer speeds was unacceptable.

So the company engineered a cross-platform A/B testing solution called ABlaze.

A test schedule view in ABlaze, the front end to Netflix's A/B testing platform.

It works like this:

When a test runs on say, an iPhone, the iOS app sends a request to the Netflix API for more information around the user, device, and session. That information is relayed to the A/B testing client, which then queries other services for more context. Then, the client passes this information to the A/B testing server, which retrieves all tests the user is allocated to, and then figures out if there's room to identify additional tests.

While this sounds complex---and it is---it allows Netflix to really push the envelope in terms of the experiments it can run.

For example, the data team at Netflix found that users look at the artwork before deciding whether to click for more details around it. So they decided to run a number of experiments:

First, they experimented with a simple A/B test to see if they could increase engagement by changing up the artwork by measuring click through rates, play duration, and other metrics.
Next, they wanted to see if changing the artwork would contribute to increasing total streaming hours across the product. They tested to find the best artwork for each title over a period of days, then served that artwork to other watchers to see if that would result in a higher number of hours streamed.
Finally, they experimented with finding a more efficient way of running the test by narrowing the number of users and time required to optimally find the winning variant for each test.

The result is that each piece of artwork that you see on Netflix may have been tested against five different variants. The important thing to note here is that Netflix didn't just decide that they were going to test all the artwork ---which would have been virtually impossible. They ran a series of incremental tests to confirm their hypotheses before moving on to bigger and bigger wins.

Work Within Constraints to Experiment Faster

While it's unlikely that most products will need the same level of internal tooling and infrastructure as companies like Facebook and Netflix, there are important lessons here for how you should think about experimentation. To experiment faster, you shouldn't start by thinking about all the *possible *tests you *could *run. Instead, start by working within your constraints and maximize for impact. Often, that has to do with optimizing the quality of data that's coming in, how you're testing that data, and how your team processes the results.

By reducing the time it takes to deploy a test and get live feedback, you're able to speed up the entire experimentation cycle and learn faster.