SD: I am comfortable standing up an automated integration and delivery pipeline.

[cottsak]

Has every SD done this?

Better question: Should every SD have done this?

Background: I would like to have every SD with the experience of having build a working pipeline end-to-end but I don't know if it's a practical ask.

[becdetat]

It's not that hard given some practice, and given that a CI environment is basically a prerequisite for any non-trivial project and SDs are routinely put into solo gigs with this requirement, I think it's pretty acceptable for an SD to at least have standing up TeamCity and Octopus on their PD radar.

[cottsak]

@bendetat Interesting. I guess it's like I thought then: It must be a WA thing. Us WA SDs are not routinely put into solo gigs with this requirement so that's where my discrepancy is I suspect. I wondered if it was something like that.

I agree that with practise it shouldn't be hard. We just don't get to practise.

[michaelnoonan]

@cottsak perhaps this could be split into two pieces? Are you willing to add some wording and a PR?

1. SD is comfortable and proactive about fixing and improving an existing CI/CD pipeline
2. SC is comfortable starting one from scratch

In QLD we've historically had many cases where D/SD/SC have landed first on a gig and set up the delivery pipes.

Regarding goals, I've had people do a one-day PD exercise where they've stood up CI/CD etc for a personal project to improve their confidence levels.

[andrewabest]

@michaelnoonan I think focusing on 'standing one up' is unnecessary - in most 'standard' situations, even without experience, I would imagine this would be fairly easy for any Readifarian. I say 'easy' as I still remember the first time I had to install and setup TC / OD from scratch when out on a solo gig :)

Perhaps the question needs to be reworded to talk about having a working familiarity with CI/CD tooling and practices?

[rbanks54]

I agree with @bendetat and @michaelnoonan. It's an expected skill for the SD level, even if they may have never set one up themselves.

We're saying SD's are trusted to ship a full product. That means we expect them to do so in a Readify way. That means a CI/CD pipeline and I'd expect an SD to be able to put a basic one together and use that rather than using that awful Deploy button in Visual Studio :-)

[michaelnoonan]

Just an additional point to the conversation: I do remember @tathamoddie mentioning some "bare minimums", like ensuring HTTPS for services like TeamCity and Octopus. Perhaps we could call out to a Readdit page like: https://readify.sharepoint.com/field-guide/Pages/Tools%20and%20Infrastructure.aspx

[cottsak]

@rbanks54 I don't have a problem with that expectation. Like I've said above, I agree it's a good idea. It just means for me that I fall short for this requirement and I'll have to remedy it with PD.

[rbanks54]

@cottsak So MadSkillz helped identify a gap? That's cool :-) If you understand the CI/CD pipeline but just haven't built one yourself, then it'd be a "maturing" rating. Oh, It's not all about just Octopus and TC either. If you can achieve the same outcome with VSO, TFS, Bamboo, CC.NET or some other tool chain then you're all good.

[chriswithpants]

It's not all about just Octopus and TC either

Yep, I believe the wording has deliberately left specific products out.

[kjacobsen]

So I was thinking about this one more a few days ago. We probably need to spell out a bunch of bare minimums and standards on Readdit and in the Madskillz (for all teams). I like the idea of a phrasinging something like, “I deploy services and solutions which ensure that security, disaster recovery, backup and compliance minimums are met, whilst ensuring that common sense applies” or something to that affect.

I would then put in a few examples, HTTPS, 2 virtual machines for each cloud service to maintain the correct Azure SLA, Azure NSGs, using an appropriate password hashing algorithm (not SHA/MD5) etc.

Some of these examples will also be gates for the migration of clients into Managed Services in the future as well. It needs to be obvious that a architected solution is supportable and maintainable and if we all have the same conception on what that is, then all our lives improve.

The line about common sense is also important, we don’t want stupid security over engineering as well.

From: Michael Noonan [mailto:notifications@github.com] Sent: Wednesday, 20 May 2015 12:44 PM To: Readify/madskillz Subject: Re: [madskillz] SD: I am comfortable standing up an automated integration and delivery pipeline. (#28)

Just an additional point to the conversation: I do remember @tathamoddiehttps://github.com/tathamoddie mentioning some "bare minimums", like ensuring HTTPS for services like TeamCity and Octopus. Perhaps we could call out to a Readdit page like: https://readify.sharepoint.com/field-guide/Pages/Tools%20and%20Infrastructure.aspx

— Reply to this email directly or view it on GitHubhttps://github.com/Readify/madskillz/issues/28#issuecomment-103733755.

[andrewabest]

@kjacobsen I think we need to steer away from being too specific with the points in mad skills. They are supposed to drive conversations that help people grow, and also help people identify with the roles they are aspiring to eventually embody. Having a large list that needs to be 'checked off' during a 'review' is kind of the antithesis of what madskillz was driving at.

When the time comes to retrospect, if madskillz has broader items, then when a team lead is holding retrospectives with their team members they can drive the conversation toward specifics within these areas to help the retrospectee either validate their skills, or shed light on areas that they may be able to grow further.

The points you have raised would certainly be valuable to have recorded somewhere, but I would expect it more to be a point of reference for people out in the field doing the job, where they could be used to review solutions and implementations.

[robdmoore]

Maybe something for field guide in readdit?

Rob Moore | Readify Principal Consultant, Technical Specialist (Microsoft Azure) | m +61 400 777 763 | e rob.moore@readify.net | w readify.net

On 2 Jun 2015, at 10:51 am, Andrew Best notifications@github.com wrote:

@kjacobsen I think we need to steer away from being too specific with the points in mad skills. They are supposed to drive conversations that help people grow, and also help people identify with the roles they are aspiring to eventually embody. Having a large list that needs to be 'checked off' during a 'review' is kind of the antithesis of what madskillz was driving at.

When the time comes to retrospect, if madskillz has broader items, then when a team lead is holding retrospectives with their team members they can drive the conversation toward specifics within these areas to help the retrospectee either validate their skills, or shed light on areas that they may be able to grow further.

The points you have raised would certainly be valuable to have recorded somewhere, but I would expect it more to be a point of reference for people out in the field doing the job, where they could be used to review solutions and implementations.

— Reply to this email directly or view it on GitHub.

[kjacobsen]

Do people read the field guide? Answer: It depends. Example: VSO access requests. If the field guide is the answer and we believe people will follow it, then I am happy to start updating it. ☺

I have seen examples where things could be better, and in other organisations, the solutions wouldn’t have been accepted. I think expectations should be outlined here. We expect people to develop solutions that meet our customer requirements, and are robust solutions in terms of security, management, and redundancy. We should all be skilling up to ensure that we keep up with these topics just as we do with the latest version of Windows or .Net.

If things are not clearly outlined, how do we ensure that reviews are performed to the same level across the organisation? How does Andrew in QLD know what security concepts he should be working with his team if he has no idea what Quinten is looking at with his?

Perhaps this is a case where Managed Services will start to include these items, and the documents and expectations will diverge.

[tathamoddie]

@kjacobsen Field Guide is a long way from tipping point yet. We need to invest in putting content there, to make it valuable, so that people will use it. Related discussion about the various Readdit priorities and progress: https://www.yammer.com/readify.net/#/Threads/show?threadId=518146777

[andrewabest]

@kjacobsen I'm not going to stray down the path of discussing possible sub-standard solutions - we should always remember the prime directive. Besides which, I would think the improvement to be sought out would be in our delivery process - i.e. retrospecting on why a given solution was delivered in a particular fashion - rather than expecting our personal development process to enforce the technical minutia that we have to deal with day to day.

I like the idea of collating the information that would be considered 'vital knowledge' in the field guide, then perhaps linking to this from MadSkillz from the broader topic that encompasses the specifics.

If we listed every detailed technical point that could be considered relevant under the current headings, the retrospective process would become laborious, tedious and for some, probably quite intimidating too. This would lead to support for it dropping, people doing it 'because they have to', and us deriving less value from it.

To your point of ensuring that we have an equal yardstick when measuring someones capabilities - this is where the duality of MadSkillz kicks in. It needs to both support the needs of the consulting pool, allowing them to communicate openly and freely as is needed to drive growth, and the needs of our HR department when they need to decide whether people are performing up to expectations, whether people deserve promotions, and how much people should be paid. The more of a 'measurement' tool it becomes, the less of a 'growth' tool it will be, as people won't be as honest and open in discussing the points if it is being used to 'measure' them to judge their bottom line.

I believe the current approach of gathering evidence from the retrospectives (which will vary a lot from consultant to consultant) and mixing this with the leadership groups opinion should lead to a fairly equitable judgement of a given persons contribution to Readify.

[kjacobsen]

I have to agree that the idea of linking field guide with MadSkillz, considering the success of MadSkillz, is a good idea. I think we should consider moving the Field Guide to a TFS/Git scenario as well to assist in the process. A linkage would help greatly, the field guide could be a secondary resource during the review process. If someone isn’t keeping up with the field guide, that can still come up during review.

Separating the two should also reduce the updates for a HR processes/MadSkillz.

[andrewabest]

@kjacobsen sounds like a winner :) decoupling it entirely will certainly help it stand on its own feet.

[kjacobsen]

It allows for more updates, more detail, quicker turn around on changes to technology and practices.

[tathamoddie]

I think re-architecting our intranet has drifted a fair way from the start of this issue, and the scope of the MadSkillz repo. Can we take this discussion somewhere outside MadSkillz?

[cottsak]

@tathamoddie Orrite! You're banned! You said "architecting".

[cottsak]

Oops. Didn't mean to Close..

Might be a good idea anyway. Meh.

[kjacobsen]

So I think we just need to add a line about following the Field Guide where appropriate and then I am happy with it all (aside from needing that updated).