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: each team is responsible for all their deployment / maintenance mechanisms separately (let's call it Scenario A) there's a dedicated DevOps ('Development Architecture') team that is responsible for deployment / maintenance mechanisms (they provide them for other teams) - for the sake of clarity, it will be Scenario B Both solutions have their PROs: In Scenario A: there are minimal external dependencies x-functional team is able to do all their work on their own if their…
All posts in continuous delivery
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 moment preparing the dedicated version for every machine (in distributed scenarios) etc. Obviously, manual configuration adjustments should be prohibited - I've already written a blog post or two about that in the past. BUT even if…
Shortening delivery cycle and improving the overall delivery pipeline gets more & more love nowadays. Delivering value more frequently, in a more predictable manner, while remaining truly transparent - who could resist that? That's why 'DevOps' & 'Continuous Delivery' are trending that high in 2014. Quite recently I've had a discussion with a more senior colleague of mine - we were discussing a particular scenario (that had some issues) in the financial market. We didn't have the first person perspective on this particular case, but we had access to some materials that shed some light into whole story - it…
I had quite an interesting discussion about frequent delivery of value via changes in software. The topics itself is not new and everyone who knows the basics of Agile / Lean approach (or just Theory of Constraints) knows that stashing the inventory should be reduced to minimum - one should deliver as frequently as possible (while making sure that delivered chunks actually bring some value), even if it means smaller portions. The Context In this particular scenario I'll write about, team is delivering more than 1 feature in the same time, BUT people work on feature sets in pairs - each…
It seems that my recent post about the sanctity of test environments was appreciated more than I expected, so I’ve decided to address another topic that too frequently gets misunderstood or which importance is usually neglected: The Configuration Basically, there are to two categories of configuration: business (functional) configuration technical (non-functional) configuration The easiest way to distinguish between those two is by finding out, who’s authorized to do the actual change. The separation should be VERY clear. For instance: business configuration should be changed only using the rights and privileges that make sense for business-oriented people.…