Crucial Techniques For Faster Software Deployment Frequency

[@ContinuousDelivery]

☀ SUMMER COURSE SALE 20% ALL COURSES 🧑‍🎓 Buy as many places as you need for you and your team and SAVE on EVERY course purchase until 31st August. Find the right course for you and your team HERE ➡ courses.cd.training/pages/buy-for-me

[@notthere83]

Nice to see a lot of the things I introduced (after discussing with the team and a number of "we're not sure but let's see how it goes and then thanking me for how smooth everything feels months later" moments) at the last company I worked at listed, even though I only did it based on bits and pieces I'd learned over the years. But I didn't do it to release faster but because I wasn't comfortable with chaos, not confident about our releases and annoyed by all the manual tasks I had to do. 😅

[@DoubleFaceReal]

i dont know how people can sleep without testing their code

[@bobthemagicmoose]

Simple, you leave your phone off ;)

[@DoubleFaceReal]

​@@bobthemagicmoose i hope your joking

[@FlaviusAspra]

They don't. Call rotation and such.

[@DoubleFaceReal]

@@FlaviusAspra yeah this has to stop

[@black-snow]

Today's shirt ... zomfg, I need it! also: first

[@legooos]

cool t-shirt

[@Rogersmith026]

What if your main client is governments and your product is desktop software? It takes them like two years to upgrade.

[@Grassyfieldsflowers]

I bet those releases are horrible! 😂

[@SirBenJamin_]

I don't know how you could achieve this for UI. If you're working on a feature that might take 3-4 days. How can you be committing this to trunk in small chunks, in its partial state, that is likely to be unstable. Its pointless writing tests as you go if those tests need to be rewritten as you go.

[@dennymeta]

Hide the feature behind a feature flag, which you can initially toggle on just for the person developing the feature, then once it's ready for testers, and finally for a small subset of users initially and slowly feed more people into the new pipeline until everyone is using the new route.

[@Joe333Smith]

'Dark launch' is one answer - deploy it incomplete but make the page unfindable for real users

[@matthiaswiehl9267]

If you need to rewrite your tests every time you make progress, it suggests the tests are too tightly coupled to the implementation details, rather than being focused on behaviour. Well-designed tests should be resilient to small changes in the code and focus on the desired outcomes rather than how those outcomes are achieved. This way, your tests evolve incrementally as your feature develops, rather than being completely rewritten.

[@chrisseamon3171]

Feature flags are the way.

[@SirBenJamin_]

A feature flag assumes its some feature that is independent and isolated within the app. Very rarely the case where I work. If we're adding something new, it is very likely the case that the new thing will interact with other parts of the system. So if you're commiting to trunk daily, there is more potential to break other parts of the system by mistake due to the feature not being complete even though the feature might be disabled. It seems risky to me to do this, when instead you could have a feature branch that lasts maybe 3-4 days, rebased daily, and then merged in when complete.

[@jacquesduplessis6175]

Sorry, never seen 1 truly effiecient dev that can have their code pass QA in one day. I generally need a few hours if explation of all the changes to QA to catch all mods and tweaks, and then still need to check personally just to make sure! What do you all think about that statement?

[@philw3039]

I'd say you probably want to figure out if it's possible to release your work in smaller increments. If it takes hours to explain your changes to QA that might be a sign your releases are too large to facilitate smooth CI/CD.

[@notthere83]

The first thing I find odd is that you "make sure yourself". Because surely, you've already done that before submitting it for review? And then your reviewer also checked it. That's 4 eyes already before QA. And as was said already, if hours of explanation are necessary, there's too much work submitted at once. But it also doesn't sound well-documented. Because the explanation for the changes should be in the ticket and/or your PR. Depending on your process, if you didn't do exactly what was described in the ticket, you'd add your explanation there or maybe link to your PR description. Again, details depend on how exactly you want to deal with it - but the explanation should definitely be in writing somewhere where everybody can see it for as long as the company exists.

[@Evilanious]

I wish where I worked could release quarterly...

[@mostafatarekadam8861]

Believe me you don't, they release quarterly not because they are cozy and fun, but because they have manual testing and shitty CI/CD pipelines that you can't guarantee your code works or not until after a long time

[@stephendgreen1502]

Sanity check: If you are filling in a tax return form you can go step by step, trying and correcting mistakes as you go, being careful with each key press, as it were, to not make mistakes. That won’t be a good way to write a novel.

[@ulrichborchers5632]

These are interesting thoughts. But IMO you are confusing a method (CD) which can be applied to an activity with the activity itself. Or can you otherwise elaborate a bit more? While the degree of creativity applied to tax forms might actually vary ... it seems that you are maybe regarding CD as a rigid activity which kills creativity. Forgive me if I understood that wrong. But if you meant it like that, then I think that "CD" would more be the part of a good software for filling out the tax forms, which does plausibility checks in real time and which gives you valid feedback of possible mistakes and suggested improvements within legal rules. It greatly reduces the anxiety of making mistakes, financial loss or punishment. It is there to ease those fears before(!) the "release". The analogy of CD for an author of a novel would be using a text editor with spell checking, finding grammar issues, suggesting synonyms when detecting repetition and so on. I guess that this would not interfere with the creativity of the author and that he or she would even improve language skills and have a better result when using a good editor for writing. And the more details you learn or get right, the more you have in your toolbox as a creative writer. Any artist wants feedback. Why would a creative software developer not want feedback for his or her work, based on facts about the result? That would be selfish and unproductive, but not creative.

[@stephendgreen1502]

@@ulrichborchers5632 If I was writing a draft of a novel, just as when I need to write a lot of code, I turn off spell checking. I turn it on when I have the substance of the draft, or the majority of the code. Then refactor.

[@MarcelloBellomi]

Love your content and your books and I really appreciate this video but it's too full of concepts if you're talking with someone with different background (es. No knowledge of team Topologies,...)

[@Marck1122]

Test automation IS NOT EQUAL TO TESTING. This is the reason that problems like crowdstrike and buggy and crap software are released every day. it's ridiculous that people claim that automated checks are the same as testing. Grow up 😭😭

[@ContinuousDelivery]

I am quite grown-up already 🤣🤣 What I describe works for world-class "grown-up" systems, manual testing after the fact, assuming that is what you are referring to, is not ever a replacement for working this way. I led a team that built one, maybe even "the", highest performance financial exchanges in the world, we were in production for 13 months and 5 days, before the first defect was noticed by a user. So this is certainly NOT a lower-quality approach. This is an engineering approach to creating better quality software. As Demming said "You can't inspect quality into a product, you must build it in"