Feature flagging in your frontend code will allow you to release continually.



## Continuous Delivery

Continuous delivery means that we release often, getting developed value to our users as quickly as we can. The master branch remains ready for production and contains all that we've written into our products.

This includes early-stage features that we'll release as well. 

## Feature Flags

Early-stage features still need feedback and testing so we can adjust them to the actual needs of our users as we learn them.  

Before we feel they're ready for all users, we'll release them to a subset of our users.  This can be accomplished with feature flags -- conditionals around who sees a feature.

Once a particular user is flagged _on_ for a specific feature, they will see or experience that feature.  If they have not been whitelisted into it, the app will look to them as though the feature doesn't exist yet.

There are many ways to implement the backend for feature flags.  Let's focus on the frontend.

## Frontend Feature Flags

The frontend in this scenario is a JavaScript-rendered UI in the browser where feature flags are simply implemented as JavaScript conditionals.

Let's say that there's a new login experience that we want to test out.  To determine if a users should see the new or old login experience, the server bootstraps the JavaScript application with data about the feature flags:

```html
<html>
  <body>
    <div class="app"></div>
    <script>
      window.env = {
        featureNewLogin: <%= serverRenderedBoolForUser %>
      }
    </script>
  </body>
</html>
```

You can use whatever data structure suits you.  This one is simple and provides the data needed for the conditional.

Then in the login UI code, we can read the feature flags:

```js
const renderLogin = _ =>
  window.env.featureNewLogin
    ? renderNewLogin()
    : renderOldLogin()
```

Simple and powerful. This allows both versions of the code to live side by side, be deployed simultaneously, but have different users experience the site differently.

What do you do to support continuous delivery of new features in your frontend code?

Feature flagging in your frontend code will allow you to release continually.

Feature Flag Frontend Code

As the software lifecycle progresses, imagine a funnel growing ever smaller.  The funnel can help control potential changes as time goes forward.  Changes are fewer.  The goal of releasing value is preeminent.



## The Wide Beginning

Creation starts with discovery.  We're talking to clients.  We're communicating with lo-fidelity prototypes -- whiteboard drawings, paper sketches, quick mockups.  The cost of change is low.  We have company meetings.  If someone wants a stake in what we're building, we're accomodating.  We want input from many.  We're trying to get a good start on the product and lots of good course corrections up front that will make large differences in where we could potentially end up down the line.

We release many times.  We go early and often.  The first releases are more experimental because we've never done this before.  A release (usually) means real software.  Real software is more expensive to make and harder to change than prototypes.  We pay this price in order to confirm whether or not what we decided to build, when it really comes down to using it, is what we needed to build.  We should be comfortable with adjusting.

## The Narrowing End

Software is never really done.  But the "end" that we're progressing toward here is a final, or 1.0, release of your software.  Your user reach is pushing to 100%.  Your feature set is coming complete.  Here there are not company-wide meetings.  We are purposefully reducing the number of daily voices influencing the project.  Stake holders need to trust and let go.  Let the creation happen.

It's a good sign if we feel our earlier adjustments have changed the software into something more solid.  We should be more sure, not at the same level of uncertainty as before.  We narrow our own focus.  The cost of change is way up now.  It should be a big deal to change stuff, because it usually is -- a big deal.  We're in finish mode.

There will be more to do after this.  There always is.  Let's release this thing so we can get on to starting a new funnel on the next thing.

## Finish Experiments

We're always doing things we've never done before.  We are always learning.  It's natural to not feel satisfied.  We push ourselves.  We're artists.  We can get halfway into a project and have either a new epiphany or serious doubts.  We get better ideas.  Our tastes evolve.  We realize this is not our best work.  Later in the funnel, this can be very costly.  We endanger our own ability to deliver value. 

If we short circuit the release by willfully changing deliverables in large ways, we stop the delivery of value.  This goes against the ideas of continuous delivery.  We keep value from reaching our customer.  We should feel uncomfortable doing major revisions on things that aren't even released.  We should honestly introspect about where these proposed changes are coming from.  Are they coming from clear feedback from customers?  Or are we molding that feedback to meet our own new desires, ideas, or tastes?  We've come this far, let's actually do it -- release it!

Barring compelling info that what you are about to release is going to flop, keep going!  Have the courage to deliver your vision.  Have the focus to not change your mind about the product that you at one point had confidence in.  Your customers will likely thank you.

How do you keep your project on track as it nears the finish line?  Do you find yourself having major (perhaps unfound?) reservations and needing to focus so-as not to derail delivery?

As final releases get closer, the funnel becomes smaller, changes should be less likely.

The Software Change Funnel

Continuous delivery allows for you to release often what you are always developing.  This is even possible on a static site where we might not be hiding in-development features but content and visual styles.  Here is a strategy for doing that, executing in Hugo.



## Feature Toggles

Main line development is a joy.  It's often good to avoid the long-lived, meandering paths of feature branches.  In order to stay in the master branch, you need to keep it always ready to deploy.  So anything that's half-baked needs to be committable but not impact the main experience. 

Feature flags generally are able to be turned on/off for all or some users.  Since we don't distinguish between users in a static site via login and since it's static, with all users getting the same content, our feature flag will be on/off for all users at once.

We will be able to turn the flag on when in our development environment.  When we build for our prod environment, we turn it off.  To enable the static content once the feature is totally complete, either toggle on the feature or remove the toggle checks.

## Hugo Environment Variables

In general, environment variables are one of the low-cost ways of implementing feature toggles.  The environment config can be updated without a deploy and feature toggles can go on/off quickly.

In this specific example, we'll look at how we can do this in Hugo.  First, we'll name our flag `FEATURE_BOOK` since we're working on a book-related feature.  Then we'll connect to environment variables using the `getenv` template function:

```
{{ if getenv "FEATURE_BOOK" }}
  Book markup here
{{ end }}
```

And then to turn the feature on, just flip the flag in the environment when running the site:

```
FEATURE_BOOK=true hugo server
```

The book markup that you surrounded with the check will be visible.  Then when you build for prod, assuming the feature should be hidden, don't set the variable:

```
hugo
```

And the book markup will not be included.

## Turning Off Content

One of the biggest parts of a static site is usually the content.  In a site like Hugo, the content is mostly held in collections of markdown files.  There's usually a way, in these kinds of blogging platforms, to mark content as not ready for publishing.  In the case of Hugo, we put this in the markdown front matter:

```
---
draft: true
---
```

If we want to easily toggle all this content on in a dev environment, we can run the dev server with our normal environment variable and the `buildDrafts` flag:

```
FEATURE_BOOK=true hugo server --buildDrafts
```

## Separate Styles

In order to separate the css that we write, we need to be careful.  It would probably be wise to test both the feature toggled on and off states before we deploy, because CSS is notoriously global.  We can affect things we don't expect, even things not covered by our feature flags.

Since `getenv` and templating in general is not available in `.css` files, we might consider splitting out a stylesheet especially for our feature flag.  Then we can surround the import from our template:

```
{{ if getenv "FEATURE_BOOK" }}
  <link rel="stylesheet" href="/css/book-specific.css" />
{{ end }}
```

Have you felt empowered to deploy more freely with your use of feature toggles?  Are there any other continuous delivery devices that you use on your static sites?

A story of my migration from Octopress to Hugo static site generator

Continuous Delivery of a Static Site

Sometimes it seems like we feel everything we produce must be our magnum opus -- not just great work, but *the* great work of our career.  Somehow we end up thinking that this thing we're working on is the final act, the thing that will dwarf all our previous work.  The thing that won't -- in fact, shouldn't -- be toppable.  We tell ourselves that we'll forever be judged by this one artifact.  Is that the case?  Probably not.



Of course we should do great work.  But sometimes our view of how great it needs to be, in a real way, gets in the way of its actual greatness.  We are slow to start.  We are intimidated by the blank page.  We shy away from production because we already don't know how to measure up to the expectation we've given ourselves in our head.  Stop expecting, and start doing.

## Why you should start now

You're probably just wasting time on stuff you don't care about while you stew about how to complete this great work by which you'll be forever judged.  Mustn't mess up now, musn't we?  Of course, you're probably snoozin' in front of Netflix right now in order to escape what you're putting off.

Life is filled with opportunities.  Opportunities don't sit still.  Time moves on.  There are windows to when things are possible or more likely.  Life will pass us by one way or the other.  Will we be involved in it in the ways we want?

There is something to be said for producing in high volumes.  I read in a C.S. Lewis biography once that Lewis' friend J.R.R. Tolkien, who worked in detail at a snail's pace, thought his friend sloppy and not as careful an author as himself (17 years of production for the 3 Lord of the Rings books vs. 7 years of production for the 7 Chronicles of Narnia books).  Yet C.S. Lewis authored [*many* great works](https://en.wikipedia.org/wiki/C._S._Lewis_bibliography) that have touched many people.  (J.R.R. Tolkien's works have spread to an even wider acclaim, btw.)  The more of your actualized ideas that appear in the wild, the more people will be touched in ways that you care about.  The more brains of your consumers that are activated by what you produce, the more ripple effect you're likely to have.  You may find a diamond in the rough eventually.  You're more likely to find diamonds if there are many scattered around for the finding.

## The Road to Perfection

The only constant is change --right?!  So why do you expect things to be *just so*, now?  This year's car model has somehow managed to look better than last year's.  But they shipped one last year anyway.  It may have even had something to do with with year's being as good as it was.

Iterate!  There will be time to repair or even replace. Often our ideas get better over time.  Often we do too much in the beginning.  We clutter the palette and crowd out great with good.  "Half baked" is just a comment with a negative connotation that means we still have work to do.  Of course we do.  When don't we?

## Those Marketing Events

Ah, those marketing events.  You know the ones.  The company is turning over new leaves and wants to make a big splash.  They want to use all that ad budget to great effect and capture all the headlines in all the outlets.

We might build something new and shiny from the ground up.  We stack as much pizzazz into the new product as we can.  We cringe that one of our favorite new features won't make it.  We endless tweak to get things just as we imagine "right" is for the big reveal.  We want it all, and it must be grand, fresh, and unified from the moment of the big press conference.

These are big events.  Sometimes they work out.  They're easy to get wrong.  They're very easy to be disappointed by.  Have you heard advice like, "Don't make 20 new New Year's resolutions.  You'll drown in them.  Focus on [1 or 3 most important things](http://jaketrent.com/post/vision-questing/) at a time."?  You'll be more likely to hit the mark you're aiming for.  And then after those first 3 months of 1 or 3 big things, your life will better in those 1 or 3 big ways.  Your product might benefit from the same focus.  And your customers will appreciate some benefits that you could provide in their lives before the appointed marketing hour.

These marketing events are kind of cool in a way.  Who doesn't like a fireworks display?  (Hehe, but if you're like me, you're thinking about the cost per firework at the same time.)  But who likes waiting for things these days either?  Do you remember the days (not far distant) where web browser releases were tied to infrequent OS releases?  Was it fun to wait a year to be able to use that new browser feature?  Thankfully, browsers are released a lot more frequently now.  Small, online patches are common.

I've never really enjoyed working toward these marketing events either.  Usually unrealistic timelines mixed with a sense of responsibility and urgency create additional stress.  Ironically, product quality and pride often suffer *anyway*, even after waiting until the big day.  The date usually moves anyway.  It's a potentially risky business move to wait on value so long, giving scrappier competitors a way to get in before you.  Things you thought would be done don't get done and you are left to create accommodations around legacy and next-gen systems existing simultaneously.  If you would have embraced iteration and expected a constant messiness, at least you would have been able to plan for this from the beginning.

## Peer in the Future

Of course you want to achieve your product vision.  You are genuinely excited by the prospects of that future that you behold.  You still can.  But if you don't release now (or at least sooner than you're comfortable), it's likely you'll never bring yourself to release, being stalled, scared of judgement, in the grips of analysis paralysis, not wanting to blow it.  Then eventually, at the end of the long and winding road, you will release what you *thought* was your vision, often missing the mark anyway.  You're more likely to hit 5 free throws than you are to hit 1 full-court shot.  And if you miss one free throw, you have another 80% of your opportunities in front of you to adjust for and get right.

It has been said that the best way to predict the future is to invent it.  A lot can change in months, days, and years.  Help guide the future one day at a time, continuously.  The best way to test your invention is to release it and let people try it.  The best time to release is as soon as possible.

Don't worry about this product being your magnum opus.  Maybe it will, maybe it won't.  Let other decide that after you're dead and all your works are done.  Make the world a better place as best you can as soon as you can, and make some opuses!

This isn't your last great work.  Stop worrying, and release.

continuous-delivery