With inspiration from and apologies to  Moving Past Shallow Incident Data.



Whether to deploy on Friday or not has become (or always was, and has experienced a resurgence as?) A Topic Of Discussion On Twitter (tm). Regardless of authors intent, I find perspectives are frequently interpreted as



• Do!
• Don’t!
• Maybe? Sometimes?



A sampling of these discussions can be found courtesy of deployonfridays.  I find there’s more to learn from longer form write-ups of the topic, and have collected my favorites at awesome-friday-deploys (awesome being the quality of the resource, not an opinion on the topic). What I haven’t seen is an examination of the complexity behind the question “Should we deploy on Friday?” For example



• What is “Friday”? From midnight to midnight? Or is it “Friday afternoon”? Starting when? Which timezone? Consider that most jobs in Israel are Sunday to Thursday.
• What is a “deploy”? Is this before or after we consider decoupling deploy from release? What changes to a system are considered deploys? Code? config? A/B test settings? WAF rules?
• What is the nature of "our answer space"? Rather than “yes” or "no", perhaps it is okay to deploy to customers in New Zealand on Friday, but not those in the United States?
• What exactly are we deploying? Should we be approaching changes to CSS the same way we approach changes to database schemas?
• Who is “we”? How does our organizational context impact not only our decision on whether to deploy today or not, but our (pragmatic) goals for the future?



I sadly don’t have answers here, and simple, generalizable answers to these questions may not exist. While you continue to contribute to pragmatic, locally rational decisions about how and when to deploy in your organization, I recommend Seeing Like a State for a discussion of complexity, simplification, metrics, and the like in settings quite far from software.