Slashdot Mirror
LinkedIn Is Open Sourcing Their Testing Frameworks (github.io)
destinyland writes: LinkedIn is open sourcing their testing frameworks, and sharing details of their revamped development process after their latest app required a year and over 250 engineers. Their new paradigm? "Release three times per day, with no more than three hours between when code is committed and when that code is available to members," according to a senior engineer on LinkedIn's blog. This requires a three-hour pipeline where everything is automated, from committing code to releasing it into production, along with automated analyses and testing. "Holding ourselves to this constraint ensures we won't revert to using manual validation to certify our releases."
What is amazing is how many people do just that.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Their Spam framework.
I think that you lost the war for 'what engineer means' when 'train engineer' became common lexicon a long time ago. Perhaps you could take the better fight that 'Software Architects aren't really Architects'.
The force that blew the Big Bang continues to accelerate.
All this efficient check in and automated testing, just so they can send spam to every email they get their hands on.
My employer specifically marks linked in spam as "NOT SPAM". So custom filters it is.
Oh my heavens, 3 hours is waaaay too long in this fast-paced, ever-changing world.
Why not just do an automatic commit with every keystroke, like the Windows 10 telemetry does?
Just cruising through this digital world at 33 1/3 rpm...
First of all, thank you Linkedin for open sourcing this! Always good to share.
First, three hours is not enough time to conduct any manual testing steps, so holding ourselves to this constraint ensures we won’t revert to using manual validation to certify our releases.
I've been in testing for some time and have been taught to make a distinction between verification and validation.
Verification is checking if the software works according to specs. Validation means: does it actually work for us. By defintion that means that you can automate verification but not validation.
Is that just semantics? Not for testers. In the test community there currently is a big debate going on checking vs testing.
See i.e. Michael Boltons blog. . Checking can be done automated. Real validation in my opinion can not.
What I am curious about is the 'to production each three hours' That sounds great, but although I don't use a linkedin app on my phone, I am still pretty sure users don't get their app update three times a day.. With such rapid deployment, I suspect it takes multiple deploments before it adds up to a significant increase in usable functionality.
Many small releases means in general that mistakes are also small and quickly fixed. I am actually in favour of them. But it is not a full garantuee that one of these small releases will not break something badly that would have been found by even a limited manual test. The chance that that happens may be much lower with small releases but it still exists and the impact is still high.
Automated tests can perform a huge amount of checks quickly. Humans can't beat that. But they can also overlook the blatanly obvious. I would hope they would have manual testing at least prior to releasing new functionality. To find these things, but also to do some validation by the definition above.
Else I suspect it may work well for them for quite some time but it may bite them badly at one point as well.
---
Hm ... I guess those guys think different: https://www.sei.cmu.edu/cmmi/
Also, what is so hard to grasp that there is no "engineer"?
There are "mechanical engineers", "electrical engineers" and others and in the end also "software engineers", I for my part actually studied "software engineering" and "computer science" ... funnily I should have worded it different, I studied "computer science" and "software engineering" is a important but depending on what else you study: a small sub section of CS.
I don't care what kind of engineer you are, that you seem so pissed, in real live I'm half an "Requirements Engineer", wow ... another engineer ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
They use MongoDB. You don't need to worry about database changes, because it's webscale.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There is no project on Earth that requires 250 developers. And yeah, the idea of continuos releases and automated testing if very common in the industry. That is what git/jenkins/buildbot does best.
Is it just me, or does LinkedIn do an amazing amount of engineering for a website that's basically a simplified Facebook + job board?
Do they really need this amount of engineering? Or are they doing it just for the sake of doing it?