Reply to post: "static" volatile dependencies

How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript

Kristian Walsh

"static" volatile dependencies

So, what you're saying is that your organisation's software development process can be stopped at any time by a third-party in a different jurisdiction. I'd love to have the kind of Programme Manager who'd hear that and say "Oh, the builds are broken? Because a guy in XYistan broke a module? And he's not answering his mails? That's fine. I'll tell the client that the service won't ship until an indefinite date in the future, and you guys can all go home early.."

The purpose of any build system is to produce repeatable outputs from your source-code, and to provide an audit trail for your releases. Repeatable is hard when you effectively do Lucky Dip dependency resolution. A build-system worthy of its name can check out any previous release of software by ID, and produce a binary-identical output product to that. A build process is language independent: you might need different tools, but using a particular language for development doesn't magically absolve you from responsibility.

Live-downloading isn't a "static dependency". "static" means "not moving", and you cannot guarantee that from a remote resource. You can barely even guarantee that if it's your dynamically-fetched resource. (Versioning components doesn't help you; you're still relying on strangers to not change code without re-versioning...)

So, if you're live-downloading every time you make a build, explain to me how you guarantee that those remotely-fetched dependencies don't dramatically change between the developer writing the unit tests, and your automated build system running them? There's a good way to waste development time. Also, how do you guard against someone maliciously injecting a backdoor into that crypto class you download every time you make a build.

More to the point (and this is the real reason companies spend money on revision control and build systems): Imagine it's next year, and you're being sued for doing something nasty, and to provide evidence of your innocence, you've got to set up a server with your company's software the way it was on the day of the alleged offence. How the hell are you going to rebuild it? Wayback Machine? Well done, you've just handed their lawyer the downpayment on a yacht.

ALL dependences used by a project must be accounted for. If you're not doing that, you're just wasting time and effort - you've got a glorified compiler/packager that offers no better consistency or auditing than just deploying straight off a developer's workstation.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon


Biting the hand that feeds IT © 1998–2020