This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation

Jump to bottom
Wesley Byerly edited this page Nov 10, 2016 · 1 revision

#Implementation Tips Here are some tips to help you integrate feature flagging into your development process.

Before you select a feature flagging method, you should:

  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?

  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?

  3. Research a build versus buy solution that takes into consideration:

    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.

  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:

    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported

  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.

Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.

About the Guide

  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content

This repository was archived by the owner on Jun 14, 2024. It is now read-only.

Implementation
Jump to bottom

Wesley Byerly edited this page Nov 10, 2016
·
1 revision
#Implementation Tips
Here are some tips to help you integrate feature flagging into your development process.
Before you select a feature flagging method, you should:
  1. Identify your current pain points - what is currently difficult to do? What issues keep arising in your development workflow? What issues keep arising in production?
  2. Identify your use cases - what would you use feature flags for? Who are the stakeholders besides developers? (Product, Business, Sales, etc) Do you want to facilitate team collaboration?
  3. Research a build versus buy solution that takes into consideration:
    • Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turnover, product neglect, and evolving product demands.
    • Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
    • Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
    • Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
    • Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.
  4. The Decision - If you’re looking to build your own platform, this page provides a list of feature flag libraries for every programming language. This can act as a nice starting point to understand the scope of the undertaking. If you’re looking to purchase a platform, you want to make sure that you are integrating a well-tested and proven solution. The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform You want to ensure that the feature flagging platform is:
    • Stable
    • Multi-language Compatible
    • Scalable
    • Intuitive
    • Well-Supported
  5. Integration and Team Coordination - Feature flag-driven development is both an engineering practice and a cultural shift for your teams. It is a practice that emphasizes team collaboration, feedback, and full release lifecycle management. Therefore, it is important that teams incorporation feature flag release strategy into their continuous delivery pipeline. This release strategy is a DevOps concept where teams integrate feature release planning into the development process. Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases. Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional. The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.
Thanks for reading LaunchDarkly’s Guide to Feature Flagging! If you have any feedback, please reach out to us at info@launchdarkly.com. We’d love your help in making this even more complete and useful.
About the Guide
  1. Introduction
  2. Uses
  3. Getting Started
  4. Cleaning Up
  5. Best Practices
  6. Flags vs Branching
  7. Blue-Green Deployments
  8. Database Migrations
  9. Implementation
Clone this wiki locally