Sebastian Gebski

There's an interesting trend of expanding the range of work products developers produce as the outcomes of their work. In software development prehistory it was just functional code (one that's supposed to provide business value directly). After some time automated tests have joined it - as a parallel code construct, meant to be submitted within the same commit. That was just a beginning, as

Sebastian Gebski

Docker is The Thing these days. Pretty much everyone has heard about it - how lean, lightweight & useful it is. Most likely you have seen the eye-catchy logo, went through very approachable tutorial, watched some basic demos. But did you try to look through the hype to verify whether it can be actually useful for you? No? Here's your opportunity, let's break some

Sebastian Gebski

There are no two dev machines that are completely alike: same software installed (& uninstalled) in the same order, same security patches applies, same OS settings, same IDE configuration. And that's great of course - developers are expected (hopefully in your company as well) to:

  • search for new "toys" - tools / libraries / add-ons / anything that could aid their work & improve their productivity
  • learn
Sebastian Gebski

Setting your applications may get really messy - especially on Linux: different applications have different configuration approaches, they keep their binaries & data in different file-system locations (these differ because apps may have origins within varying Linux distributions). Once you set things up once, it's pretty hard to restore the previous state, especially if you've made some other changes in the meantime (for instance

Sebastian Gebski

Straight to business - I've participated in a very interesting discussion about development architecture recently: which scenario works better & brings more benefit to the organization:

  1. each team is responsible for all their deployment / maintenance mechanisms separately (let's call it Scenario A)
  2. there's a dedicated DevOps ('Development Architecture') team that is responsible for deployment / maintenance mechanisms (they provide them for other teams) - for
Sebastian Gebski

Dealing with technical configuration of your apps may be tricky. In a simple case you just slap a text file or two and there's no harm done, but once your solution gets more & more complex, all those pesky files get really cumbersone:

  • keeping the content of them all in sync
  • modifying the large number of them (usually remotely) in virtually the very same
Sebastian Gebski

All the considerations below are based on DevOps <-> Dev scenario, but IMHO vast majority of them applies well to any supplier <-> buyer scenario.

DevOps' reality is somehow simple:

  • they work for other developers (their "clients")
  • their goal is to make other developers focus solely on the business functionality, without caring much about setting up the development process or deplyment pipeline
Sebastian Gebski

Another day, another interesting discussion, another topic for a blog post: the operations procedures (aka handbooks) in agile environment - should we bother writing anything down? If so, what for?

The Context

Imagine a DevOps team that works on operations for several actively developed, interconnected applications:

  • work happens in several streams that may be parallel
  • there are many test environments, continuously (or close to)