This week we talked about deployment strategies. Besides being a favorite pastime of the DevOps community on Twitter (see: deploying on Fridays), this topic is especially interesting when we think about how it has changed over the years. We have iterations we go through as software evolves—what works, what doesn’t, how we implement things in different ways, etc. And it weaves into a common theme: Knowledge.
We know the quote “Knowledge is Power,” but Israelmore Ayvior takes this a step further:
“Knowledge is Power, Power provides Information; Information leads to Education, Education breeds Wisdom; Wisdom is Liberation. People are not liberated because of lack of knowledge.”
This leads to some interesting parallels between software, technology, and the people implementing it. With each iteration of the technology we have discovered or created, we are doing so with knowledge as people. From this, we have knowledge we share as “best practices,” and continue to learn and tweak the process to make it better. That wisdom comes from your understanding of something, which is a powerful tool that can create liberation. It can also create the opposite effect, gatekeeping.
As we learn in software, we are enabling power for some and gatekeeping for others. With deployment strategies, we have created better processes over the past 10 years, ranging from working with FTP servers to automating builds. The concept of deploying itself is intimidating; we are taking what we’ve created and letting it out into the world with hopes that it will be welcomed by the world known as the internet. “Does it work the way we expected? Will anything break with this update? Have we thought through all the challenges associated?” This among many reasons, is why we love using feature flags for our deployment—our testing in production—because it’s a safety net. It allows us to see these changes we made in a smaller scope, a safer exposure without impacting everyone else.
We take our knowledge, turn it into power, which leads to information for us to share with others. With all that philosophy talk, let’s dig into our questions this week and some of the themes we saw.
🏎 How frequently do you deploy?
💭 How have your strategies changed over the years?
🚀 What are you currently using for deployment, what do you wish you were using?
We had participants who deployed to local servers once a week, to every day. Seeing some companies having a continuous delivery process versus manual makes a big difference in their lives!
It’s interesting to remember how many of us did the FTP transfer of squint “I hope this works” and looking at how different things are today. Education truly does breed wisdom, it only takes one of those moments of deleting a file on production to learn how to NOT do it again and create the wisdom to influence future behavior.
My first "deploy" was for a website I made around 2002. I didn't know anything. The process involved copying and pasting files from my computer into the cPanel FTP thing. #ToggleTalk— Lev Lazinskiy (@levlaz ) May 6, 2020
I remember upgrading phpBB on a live server for my second job because we had no other way to do it.It took weeks and the entire forum was basically broken the whole time. #ToggleTalk — Lev Lazinskiy (@levlaz ) May 6, 2020
Back in the day I don't think I even knew FTP came in an SFTP form. Let alone worked somewhere that had it enabled. The number of large corporates doing payments and money transfers using FTP ... I am sure they've all fixed that by now...— James Turnbull (@kartar) May 6, 2020
Deployment strategies is a great topic for us to discuss as it can go to so many areas. This week focused on a lot of changes we’ve seen previously, however we could focus on any of these one topics and have a whole post about it! One of the important things to remember is there is no one-size-fits-all approach when it comes to deployment for your team and project.
As we continue to build these technologies and practices, keep in mind how approachable they are to people. Remember to share your knowledge, not keep it to yourself. We make our industry better by sharing and enabling one another. And as builders, we can help by enabling our software to help, not hinder people and processes.
As always, thank you everyone for coming and participating in our talk this week.