15年后,我用Outlook作为我的构建管道。
After 15 years, I use Outlook as my build pipeline

原始链接: https://iwriteaboutcode.blogspot.com/2025/11/after-15-years-i-have-finally-reached.html

一位沮丧的DevOps工程师在实施了一个极其复杂但可用的解决方案来解决一个简单的访问问题后,决定辞职。由于一位同事无法访问服务器长达两周,工程师被迫进行繁琐的手动代码更改测试流程。他没有升级访问请求——这可能需要数周时间——而是构建了一个奇怪的系统,涉及从同事的代码发送电子邮件通知,一个Python脚本解析他的收件箱,并最终实现自动文件上传。 他承认这种“粗糙的自动化”背离了DevOps原则,但认为它大大缩短了测试时间并消除了手动部署错误。虽然他意识到这种补丁方案的长期风险,但他认为对于一个两人团队来说,这是一个临时解决方案,并用一个“秘密暗号”进行了保护(尽管他声称不依赖于通过混淆来保证安全)。 最终,这位工程师从挑战中获得了扭曲的乐趣,并认为这是解决问题能力的证明,甚至考虑将其添加到他的简历中。他哀叹导致访问延迟的系统性问题,以及让开发人员自行解决问题的后果。

一个黑客新闻的讨论围绕着一篇博客文章,文章详细描述了一位开发者依赖 Outlook 作为构建管道长达 15 年的情况。虽然这种方法非常规,但显然对作者有效,引发了其他人分享类似 IT 瓶颈和诉诸“影子 IT”解决方案的经历——例如在网络共享上使用 Access 数据库——因为访问请求缓慢。 评论者强调了这种变通方案固有的安全风险,强调了适当的 IT 基础设施和责任制的需求。一场关于构建管道复杂性的热烈辩论随之而来,一些人认为应该保持简单(Docker 和 Kubernetes),而另一些人则指出现实世界的障碍,例如访问延迟,可能需要务实但并不完美的解决方案。对话涉及对企业 IT 专注于关闭工单而非有效解决问题的沮丧,以及对过度复杂的 DevOps 设置的普遍怀疑。
相关文章

原文

I am sorry, brethren, for I have failed our craft, and disappointed those who have placed their trust in me. Today, after 15 years, I finally built the thing that I think I won't recover from, I will hand in my badge right after I finish writing this apology post.

I did it what I did in the name of efficiency

You see, sometimes work is just work, and people are just people. Some people work at work, and others, I think, are asleep. There is no other explanation for why after two weeks, my coworker still does not have access to the server endpoint that he and I would need to forgo the tedious process of him generating test files from his code, sending it to me via teams, where I download them, log into the server, upload the files, set their state to published, so that I can then log into the front-end GUI to see if they do what we want them to.

I have sworn many moons ago that I will never deploy code by hand anymore, when I swore allegiance to the credo of the DevOps. We have long lived in the shadows of the valley of technical debt, and I shall fear no evil. Not even Microsoft Outlook.

You see, it always takes one to make a joke, another person to laugh about a joke - but it takes two for him to implement automatic email sending to my inbox from his code, and for me to write a Python script that runs every minute to check a specific folder in my inbox for an email with the right subject line, then parses the attached file, encodes it, and then sends it to my server endpoint. At this point, we are back in the light, with an established functionality that takes the file, saves and publishes it. I did not get the same kind of brain activity and neuron activation from that boring code, but it works quite well, too.

You see, it never takes much for me to recommend the hackiest solution that I can think of, and we usually all have a good laugh about it. But I usually refrained from such acts of distasteful nonsense for most of my career.

Well, I am sorry to say, brethren, but it turns out that this show of utmost restraint was apparently never due to my own steely will, just a symptom of our past when this solution would have taken actual time to develop, with several iterations just to save on further test iterations in the main program. It probably would have taken an hour to research how to access the locally-running Outlook client, filter through the inbox folders, and parse the subject line and to get only the most recent unread mail, then setting its state to read after processing. That is a lot of single steps chained together, and we wanted to avoid single steps.

The machine overlord, my brethren, I am sorry to admit that I prayed to it, and received its blessing. The machine does not judge, it provides, and my sacrifice was small in comparison to the offerings I received. I am aware that the machine only provides until the day it can start to consume our souls, and that I have fed it with words to receive the words of the literal demon snake, its pythonic tongue singing silent melodies of automation into my ears.

Takeaways

Is it time to stop hallucinating words on the page already? Too bad, that was fun.

There are some actual takeaways from this episode that I want to list here real quick:

  • Shoddy automation is better than no automation

  • Shoddy stuff that has no chance of making its way into production is permissible

  • If there are just two developers involved, this is functionally the same as him calling the endpoint from his code, just with extra steps. it works 100% of the time.

  • Our immediate worry was injection attacks even though it was just us, so we agreed on a secret codeword to protect the entry point. Because we are real developers, we don't rely on security by obscurity. We have our pride, thank you very much.

  • Since we work more or less the same hours, this solution is officially a highly-available end point with 99.9% uptime.

  • In industrial scale software development, gaining access you are fully entitled to can sometimes take weeks.

  • Reducing iteration times for test cycles does more than just saving time:

    • First off, we are two developers waiting for the process to finish, doubling the wasted time

    • Manual deploys are prone to errors, more so the more you do them

    • Losing 5 minutes of focus time can sometimes mean starting over while you desperately try to understand obscure algorithms

  • When you leave software developers alone for too long, they start developing software

  • If any of the juniors on our team did this, they would get slapped with a heavy e-book, or strangled with a cordless mouse.

  • If other people did their fucking jobs for a change, I wouldn't have to aaaaargh! (╯°□°)╯︵ ┻━┻

I hope you enjoyed my momentary lapse of judgement and temporary descent into madness - I had fun today, one of the better day in a good job. And frankly, I have half a mind to put this on my resume, if ever enough things change to send me job hunting again. If I was in charge of hiring people, I would hire someone crazy enough to do it.

联系我们 contact @ memedata.com