Definition and promotion of standards to enable automation and best practices for DevOps while preserving innovation.

1. USING STANDARDS
FOR GOOD
Sept 2017

2. NEIL MCCAUGHLEY
BUILD AND RELEASE ENGINERING MANAGER

3. What are Standards?
• AKA
– Policies
– Best Practices
– Procedures
• Definition:
– A model or basis of comparison
– An agreed upon set of characteristics, definitions and/or
practices
– A minimum acceptable benchmark allowing for
quantitative or qualitative judgement

4. • British standards institution (BSI)
– A National standards organization whose primary activities
are
• Developing
• Coordinating
• Promulgating (promote)
• Revising
• Amending
• Reissuing
• Interpreting
Or otherwise Producing technical standards that are
intended to address the needs of a group of affected
adopters
Standards IRL

5. BSI Example
• UK rectangular 3 pin plug
– BS 1363 – Plug and outlet
socket system
– Introduced in 1947
– One of the new standards for electrical wiring in
the United Kingdom used for post-war
reconstruction
– Introduced in common 3 rectangular pins design
promoted as the "all-purpose domestic standard"

6. World leader in plug game
– Fuses Only plug standard in world
that has fuses internally
– Shutters For safety
– Long earth pin Ingenious method
to open shutters
– Wiring BLUE Left, BROWN Right
– Plastic shielding Prevents shock if
you slip you finger in
– Inner leads order If you pull the
lead out you wont die
– Earth wire Return path to ground
– Cord grip and cord position
Prevent ripping out from wall
2
1
3

7. World leader in plug game
– Fuses Only plug standard in world
that has fuses internally
– Shutters For safety
– Long earth pin Ingenious method
to open shutters
– Wiring BLUE Left, BROWN Right
– Plastic shielding Prevents shock if
you slip you finger in
– Inner leads order If you pull the
lead out you wont die
– Earth wire Return path to ground
– Cord grip Prevent ripping out
2
1
3

8. Tip #1 Some standards can be painful
if stepped on

9. • RELENG
– Internal development and enablement team whose primary
activities are
• Developing automation
• Collaborating
• Promulgating (promote)
• Revising
• Amending
• Supporting
• Interpreting
Or otherwise Producing source control, code path, build,
orchestration, packaging and deployment standards that are
intended to address the needs of a group of affected
adopters (Development and Operations)
Release Engineering Standards

10. DevOps Example
• Build and package steps on Integration/Trunk
branch
– Enables automation for developer
productivity (CI/CD)
– Promotes Best Practices
– Reliability with Self Service & automation
– Consistency e.g Naming across the board for each service
( service name = repo name = docker image name = package name =
monitoring name)
– Ease of development for developers with common libraries. No reinventing
the wheel
– Cost savings across the board
• Lower support effort - expertise in finite number of scripts/tools/practices
• Lower licensing cost
– Known quantity - Ensuring reliability, scaling

11. NantHealth Build template
– Verified Pathway With triggers and gates
– Uses a Consistent build tool
(and Build tool version e.g. Maven/Nuget)
– Semantic versioning through rules
– Compliance - Test coverage and security
scanning
– Targets correct internal dependency
packages based on its status in its
code path to production
– Resolves Dependencies from trusted
sources
– Deployment preparation
– Self service ability - Ensuring
consistency

12. – Targets correct internal dependency
packages based on its status in its
code path to production
– Resolves Dependencies from trusted
sources
– Deployment preparation
– Self service ability - Ensuring
consistency
– Verified Pathway With triggers and gates
– Uses a Consistent build tool
(and Build tool version e.g. Maven/Nuget)
– Semantic versioning through rules
– Compliance - Test coverage and security
scanning
NantHealth Build template

13. Tip #2 Level of RELENG ownership is
required for support and improvement

14. Risks of Standardisation
Subverting a standard
• Advantages
 Quicker
 Suits my way of working
 Feel like a Renegade
• Disadvantages
– May not work
– Extra work required at a different stage of
the pipeline
– Introduces risks to other parties
– Leaves a trail of destruction
• Engineers are smart – They will
find a quicker path
• There are 300+ Developers to
support. NOT EVERYONE IS
ALIKE!
• A lot of Engineers think every
engineers works like them

15. Tip #3 If you optimise for individual
productivity - by definition:
YOU DO NOT HAVE A TEAM

16. Risks of Standardisation
Mass Standardisation
• Advantages
 Less risk
 Lower long term cost
 Consistency
 Known quantity
• Disadvantages
– Enforcing standards too strictly, can lead
to lack of innovation
– Prevents teams from achieving their
potential
– All you’ll achieve over time is mediocrity
– Time is spent compromising
McDonalds have consistency on
their side. Go into a McDonald’s in
Belfast and have a cheeseburger –
it’s likely to taste exactly the same
as a cheeseburger from a
McDonald’s in Moscow

17. Standardisation done right
Promote Flexibility with High standards
• Advantages
 Promotes innovation
 Lower short term cost
 Value
 Happy Engineers
• Disadvantages
– Potentially more expensive to support
– If not reviewed it can introduce risks
– Trust and buy in required
– Only works with good culture
A Michelin starred restaurant has
standards in quality of produce
and standard of service, giving
Chefs ability to innovate year on
year

18. Tip #4 It’s not wrong to use
standards as a
BASE FOR REASONING

19. Promoting Flexibility
• Standards should not limit the scope of thinking
– e.g. The build command will call
– Which in turn calls the build.proj hitting the CI target.
– The CI step will resolve dependencies, compile and build package.
– This is templated out with a Project-init tool and you can customize the
build.cmd, build.proj and .sln files as you see fit.
– The BASE FOR REASONING applies here
– You can do what you want as long as you give me:
• Defined targets
• Valid dependencies
• Level of code coverage
• …
• Code that build agent can build
PS C:> build.cmd /t:CI /p:Version=%project.version%
/logger:JetBrains.BuildServer.MSBuildLoggers.MSBuildLogger,%sy
stem.teamcity.dotnet.nunitlauncher.msbuild.task%

20. Promoting Flexibility – Further examples
• Deployment scope
– Automatically generated Chef cookbooks upon push to source control
– Set of Providers per package type that hit the marks for BASE FOR
REASONING to
• Pull artifacts form the correct location
• Have consistent install steps
• Log and event correctly
• Follow SCM format
– Cookbooks are customizable outside of base install
• Container scope
– We provide support for number of Docker Maven plugins (Spotify, fabric8)
• We don’t need these on our build agents
• Build configs are design to allow flexibility and are the same
– We promote other standards
• Internal registry
• Package promotion

21. Promoting Flexibility
• Providing for Continuous improvement
– Standards will never be perfect
– Times/Tech changes
– IRL. Remember this loophole
– This is due to be fixed in next iteration of BS 1363
– Previous iterations of BS 1363 introduced
• 1957: Surface mounted switch outlets
• 1984: Sleeved pins became required by the standard

22. Promoting Flexibility
• Sandbox Environments
– Isolated from Dev Pipeline
– Elevated privileges for all
– Collaborate with RELENG on setting up
– Review with RELENG/Other teams to promote
– Tooling Jenkins, Gitlab, docker allow to deviate
• Temporarily detach
– Exceptions provided at isolated development level
– Permissions / restrictions controlled by RELENG
– Process defined and owned by RELENG
– Controlled through JIRA
– Collaborate with RELENG for Review
– Promotion based upon viability / cost / value

23. Tip #5 Collaborate, Collaborate,
Collaborate

24. Arriving at a Standard
• Identify opportunities for improvement
– Flawed standard
– New Technologies
– Automating manual process
• Encourage Change
– Promote safe mechanism for change
– Collaborating to compromise and agree standards
• Defining the standard
– Through documentation
– Enforced through scripting/tools
– Monitor deviations
– Track changes through collaboration tools

25. Tip #6 Don’t get carried away

26. Jerry’s Final Thought
• Standards are a BASE FOR REASONING
– There are certain benchmarks that impact more than your work
• Standards are never perfect
– Make your improvements “The new standard”
– Contributions are required by all
– Have a lightweight process and system that can support change to
standards
• Do not conform. Be flexible
– Until recently the general mantra has been “standardise and conform!”
– Sustainable systems that allow for developers to make local choices that
work for them

27. Twitter: @neilisking
Linkedin: https://www.linkedin.com/in/neil-mccaughley-a80739a/
Slideshare: https://www.slideshare.net/NeilMcCaughley
THANKS