The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Alex V (4) [Avatar] Offline
#1
First off, I very much like the fact that you explain the psychological aspects. People I've worked with were often unaware that this was the big "nay"-sayer in their heads; stopping them from achieving true progress.

In addition to that, I've learned from people more knowledgeable then myself, that most of these symptoms are caused by something called the Dunning-Kruger effect. You think you know something, and a possible result is that you either fear it or feel frustrated about it. The end result depends on your experiences within the project, as you describe very well in your fear&frustration paragraphs.

Page 29:
How does the kibana+elasticsearch+fluentd stack compare to .net's application insights? I was looking around a bit, and I think it's close to an equivalent?

Overall: I like this chapter as an introduction to the world of QA. As you are undoubtedly aware Implementing a full CI toolchain can be quite a hassle, and is something I personally would not let everyone do as it requires maintenance, process and IT knowledge. Is Part 3 taking care of the complexities of such an endeavor?

Maybe some references to books or blogs at the end of the chapter could help the reader understand the depth of the subject of implementing the toolchains?
chris.birchall (13) [Avatar] Offline
#2
Thanks again for the feedback. I'd never heard of the Dunning-Kruger effect. It's interesting, but also a little worrying - I wonder where I am on the scale between "idiot who thinks he's a genius" and "genius who thinks he's an idiot" ...

I don't know much about Application Insights (as you can probably tell from reading the book, I don't have much experience with the .Net stack), but from what I found online it looks quite similar to the Kibana + ES stack that I describe. It looks like Application Insights is available as a hosted solution on Azure, which is great. The more of this kind of stuff you can outsource to somebody else the better! A similar service that I have experience with is New Relic.

Implementing a full CI toolchain can be quite a hassle, and is something I personally would not let everyone do as it requires maintenance, process and IT knowledge


I beg to differ about this point. While setting up and maintaining a full CI pipeline is a lot of work, it's also really easy to get started and gradually expand your usage once you become familiar with it. I also think frontline developers should be the people to maintain the CI toolchain, as they are the people who know best what their CI needs are. I have worked in a company where the CI server was locked down and only the ops team could maintain it, and it was a real hassle for everybody, with developers having to make support requests for every tiny settings tweak. As soon as we transferred the maintenance responsibility to developers, everybody became more productive.

There are plenty of hosted CI solutions such as CloudBees, Travis and Wercker, which can help to reduce the maintenance burden, but if your source code is hosted in-house or you want a heavily customised pipeline then an in-house CI server is the only option.
Alex V (4) [Avatar] Offline
#3
Dunning-Kruger can play tricks on you once you know about it's existence. Some of Juval Lowy's videos on youtube explain it's mapping and understanding onto the developers life. In general, his talks are worth anyone's time smilie.


About the CI setup: I agree that business agility needs to be protected at all times.
I would be interested in some insights:
- how did you manage spreading the knowledge throughout the devs? Some VCS voodoo are important factors in setting up and maintaining such systems...
- how did you avoid constant (breaking) changes in the CI system? Did you do it through constant education? Daily alignments? Training sessions about detailing build systems?
- did you measure the time spent by every dev on the CI system? I mean, if the cost justifies a single IT guy as a direct support guy, then how was the decision made to increase the team overhead? (a misleading/suggestive question, sorry for that)
- did you measure the time won by moving it from the IT guys to your team?
chris.birchall (13) [Avatar] Offline
#4
We went from one extreme (totally locked down Jenkins) to the other (any of about 50 devs could update the Jenkins configuration, install plugins, etc.), but that turned out to be quite chaotic and unstable. One developer installing a plugin could break CI for a developer on a completely different team. Eventually we settled on separate Jenkins instances for each of the teams that used CI heavily, plus one shared instance for everybody else. This worked pretty well.

We didn't do any formal training, but we had a pool of senior developers who devs could turn to for support/advice concerning the CI setup. These CI experts also tried to promote best practices and maximise consistency of usage between the various Jenkins instances.

Unfortunately I don't have any hard numbers about time spent/saved, only anecdotal evidence. But overall I think it was the right decision. Empowering the devs by allowing them to take control of their own CI infrastructure was good for motivation, and (once things settled down after the initial teething problems) devs didn't waste too much time on CI yak shaving.