These are environments where sudo is not available, leaving out commands like npm link.

I'll duplicate the process of running npm link manually, in directories that are not located in /usr/, etc.

Go to http://andrew.yurisich.com/search and click the first link. It won't load. Click to open it in a new tab though, and it will.

This doesn't happen for me locally.

POCDR ("Proof of Concept Delivery/Rollback") attempts to define a generalized CI/CD methodology for engineering the maximization of confidence in a production deployment.

Essentially, it is a logical extension of the canary deployment model, but for systems in which a phased rollout is not realistic or feasible. It does this by offering a more explicit strategy for applying overlapping concepts from the 12-factor app, cloud native, infrastructure as code, and Google SRE manifestos. While it does more or less rephrase inter-related points between those approaches, it does so in a way that specifically focuses on solving traditionally hard problems in changing production systems which:

• are mission critical
• have sensitive uptime requirements
• are on the write path
• struggle to justify the risks associated with:
  • adding new features
  • basic system maintenance (e.g, dependency updates)
  • decomposing responsibility (i..e., "microservice fragmentation")

Especially if they:

• have a write path which cannot be parallelized
• have a large "blast radius" of downstream systems
• rely on system-wide infrastructure with similar constraints
• is itself a said system-wide infrastructure component
• must detect erroneous system output and apply alterations afterwards

Kubernetes, kafka, cassandra, and git are referenced, but only for an example implementation.

Bedrock system components are expected to have a reasonable granularity to their access control features.

Include the "city water purifier" analogy.

Include a high level summary of the principles of a POCDR-compliant system, similar to the approach used in Google's SRE manifesto.

Includes a breakdown of the high level summary as a chart outlining the "Levels of Maturity", similar to how this article does it.

Some people enjoy the idea of a nice, tidy squashed pull request to keep things clean in the revision history. Others insist that the full changeset, warts and all, needs to be present in order to better understand how the feature came to be. Was there a separate refactoring step in there somewhere? Which tests were being difficult when implementing the new feature?

Get the best of both worlds! Check out new branch at the tip of the unsquashed branch named {{BRANCH-NAME}}-squashed and then squash it. Push it up as the "official" pull request to keep the version history clean (with about 75% less commits!), while giving developers the opportunity to check out the branch minus -squash at the end for a fine-grained look at the real history behind a feature.

Related to #52, might as well just get rid of the problem altogether instead of patching it over and over.

Also, consider upgrading everything -- redcarpet to kramdown, upgrading lanyon, etc.

Everyone loves color themes. Dark and light are great, but "16-bit" inspired (and other pattern-based layouts) are more fun to implement, especially if your CSS isn't the best.

Reluctantly accept that most developers will always gravitate toward time-based estimates, even if there's evidence saying that it's not a good idea. Instead of dying on this hill over and over, embrace time estimates using the rule of two. Instead of "points", use

• minutes
• hours
• days
• weeks
• months

Where the upper limit on each is exactly two of the next unit. e.g., a "minutes" estimate would be work that takes anywhere between 1 and 120 minutes, since that is two hours. An "hours" estimate would be take between 2 and 16 (work) hours, or two days. And so on.

A docker image for running jekyll is much simpler to get going with than installing rvm.

Walk through the steps that happen in rackerlabs/encore-ui-screenshots, and document those more closely.

If you push something out and it's not right, don't go fix it right away unless it's an emergency.

You don't stop batting practice just because you missed the ball. Don't walk over to it and try and pick it up, just stay put and focus on the next one.

If you have standup later in the morning/afternoon, or you work remotely in another time zone than your team, this can prove to be especially handy. Make sure you let your team know what the file is if you're going to be getting online before everyone else the following day, especially when first starting out. This will help you stay focused, have clear direction, and plenty of work already imagined for yourself that day.

At the end of your day, find a place in the codebase that has open, assigned work pinned to it via a story. For an added bonus, open the files in your editor, and simply put your computer to sleep.

Don't do this:

Do this:

There's going to need to be a lot of primer material for just make, but eventually it should culminate at introducing some wrappers around not just k8s, but also gcloud, terraform, and awscli.