This blog post is all about: the difference between focus on doing and focus on getting done, importance of owning your own metrics (KPIs), why data can be double-edged sword (but the transparency is still the key), that engineer who doesn't introspect into her/his work can be effective only by pure luck and that falling into "victimship" (instead of trying to fix the issue) has never ever fixed any problem.Part III of the series can be found here.Disclaimer: to make this as brief as possible, I've filtered out several side topics - e.g. test pyramid consideration,…
All posts in continuous delivery
This blog post is all about the difference between operational & aspirational work, how does the waste disguise itself, why QA is so prone to over-doing, that QA is much more similar to other disciplines of engineering than one may think, how making things visual helped us a lot with stopping starting :)Part II of the series can be found here.So, how far did we go in the last part? Not that far to be honest, we've identified some ways to "free the mandays" & started implementing them - but this was just the beginning of our journey ...Increasing…
In this post you'll read about the difference between writing automated tests & having testing automated, why testing framework or DSL used do not really matter, what does it mean "to free the mandays", how did we approach securing capacity for kick-starting test automation with a big hit.This is the 2nd post in the series. You can find the previous episode here.Just do it (not)!It's a very banal truth that it's very easy to create automated tests, but it's very hard to automate testing.Uhm, wait, what? What's the difference?I can easily create zillion of automated…
In this blog post you'll read about why & how Shedul has started the journey towards Continuous Delivery, what does it have in common with test automation and why 2 weeks are both a little & a lot ...Dunno about you, but I love the warstories. Theory is great, but even the greatest & most thoroughly thought-through ideas do not guarantee a success - it's (almost) all about execution and learning from successes & mistakes (both your own & others'). I have shitloads of my own stories I'd gladly share, but in many cases I simply can't - as a…
"Organic" growth Codebases grow, they never shrink. New functionality chunks appear, old ones very rarely get decomissioned. More code means more complexity, more dependencies, more space for regression & even more troublesome testing - that's sad reality & you can fool yourself with dreaming about full decoupling, atomic services & independent modules, but in majority of cases - this is not going to happen. Back to reality then - you can still consider yourself lucky if: you're not doing big projects (but the series of small ones) or you're doing big projects that are splittable into small increments…
When I was working about my last blog post, the one about outsourcing the pain, I've come up with an idea of one, interesting type of pain software developers tend to forget about. Wait, they don't forget about it, they usually intentionally pretend it does not exist: the pain of massive data inertia. As close to production ..., right? One of the main reasons why developers share their development environments (and cripple their development agility) is their insatiable hunger for data :) Everyone would like a full-blown copy of production database - surely, in 99% data is properly scrambled, but the volume…
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…
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…