It’s been a long time.., and… as some of the inner circle already know.. I have defected …
Well.. by defected, I mean I am no longer a developer by day (still helping on Glass and some project work by night.) I decided that I would try and make an active change in my working in life to start working in the arena I feel plagues most projects I have worked on… Delivery (DevOps)..
I thought I would start looking at a series focused more on delivery of systems and solutions on the platform including commmon scenarios, potential solutions, etc.
I am a great believer that your team cannot be agile if you cannot deliver. In fact, I would go so far as to say that delivery is THE MOST important part of any teams lifecycle, yet is often paid the least attention. From my near 20 years in development, I have worked in many teams, with many truly great (and not so great) developers and I have noticed very consistent traits.
- Lack of understanding of delivery
- Fear of releases
- Lack of consideration for delivery
I also have encountered large software houses trying to explain / coach the ‘agile approach’ or ‘agile methodologies’. To me, being agile is really simple.. you can deliver working code on demand..
For me, as a(n ex) software developer and as a DevOps engineer. It is my belief that you cannot be truly agile unless you can deliver REGULARLY (like, daily, bi-daily regularly)
As is always the case you have your two major limiting factors
To deliver quality software it is fairly universally understood that you can only generally deliver to one of these, as both commodities are fixed.
To this end, I have formed a few tenets that I work to when it comes to what I believe agile software principles. Please note, these change by the day, this was today’s version.. I haven’t got it fully right yet.. but these at present are my current holy grail.
- If you produce your deliverables (for code that is meant for production) from different branches, you are doing it wrong
- If you can’t deliver today, you are doing it wrong
- If you can’t deliver whenever you choose too, you are doing it wrong
- If the development staff cannot reproduce your delivery, you are doing it wrong
- If you deliver to the same infrastructure each time, you are doing it wrong
- If you deliver incremental updates to the same platform, you (not withstanding true modularisation which is really rare on the Sitecore platform) are doing it wrong.
- And…. most important… the people that perform your releases should be qa / business people, not techies! Developers, devops, operations / it bods have no place in sending releases live. They are there to consult and ensure it goes ok.
In my utopia, I would even go so far as to say, server side branches & pull requests in a agile software team are also non-productive – but that’s a different post entirely.
In subsequent posts, I will look at immutable infrastructure through to delivered code and my take on the pitfalls, challenges and solutions to the issues I have seen near daily since I embarked on my Sitecore journey.