Getting Configurations Under Control - First Steps – Marcin Niewiadomski

Getting Configurations Under Control - First Steps – Marcin Niewiadomski

One of challenges we had in our system is huge amount of parameters (literally tens of thousands). Such huge amount of parameters leads to long deployment preparation times. And things can still get “broken” too as system sometimes manipulates configuration on its own.

Of course the real solution is to deliver proper configuration automatically, but you need to start from somewhere.

The talk would share our experience from simply putting all of those parameters spread among hundreds of files into distributed version control. Solution seems to be “too easy” (Mercurial + symbolic links), but helped us a lot and allowed to identify places, where the system “messes itself up” and allowed to solve issues much faster. Such approach can be applied as well with different DVCS and also for non-Windows platforms.

I’ll also mention the importance of working with users and that value of them is much more important than technical excellence.

It hope it will be inspiring for people who have a similar challenge in front of them, but somehow don’t know how to start or don’t believe such a simple thing will works.

027edc76bf9f9c030820807f87c5dbdc?s=128

DevOpsDays Zurich

May 03, 2018
Tweet

Transcript

  1. GETTING CONFIGURATIONS UNDER CONTROL - FIRST STEPS Marcin Niewiadomski

  2. ABOUT ME Coding since age of 7 Software Engineer Software

    Architect System Architect Build Manager SCRUM Master now – Senior DevOps Engineer
  3. OUR CHALLENGE DELIVER A RUNNING SYSTEM

  4. None
  5. ABOVE 50.0000 PARAMETERS PER DEPLOYMENT

  6. GOAL OF TESTING

  7. SERVICE MAN

  8. Invalid configuration in 90% of cases Totally surprising in 30%

    of cases
  9. from DEV world MERCURIAL  (DVCS like GIT) from OPS

    world  NTFS (symbolic links)  bgInfo (Sysinternals Suite)
  10. WHAT WAS GOOD

  11. WHAT WAS BAD - DVCS is not so easy at

    the beginning - Low-level representation - System doing changes by itself!
  12. WHAT WAS UGLY

  13. USERS CARE ABOUT COMFORT NOT TECHNOLOGY

  14. PICK RIGHT PEOPLE AS PILOT CUSTOMERS

  15. IGNORE NAY-SAYERS

  16. „In this repository, we build a kind of knowledge base”

    Test engineer who uses it daily
  17. „It paid back already” Test department manager 2 weeks since

    rollout in the first lab
  18. DIFFERENCE BEFORE Days to weeks to discover Hours to days

    to figure out and fix AFTER One minute to discover One minute to restore
  19. YOU CAN MAKE A REAL DIFFERENCE WITHOUT FANCY STUFF

  20. Thank You !!!