Great! Should be essential viewing. So glad to finally have a source I can give to engineers which gets the fundamentals across concisely and clearly. Thank you!
I had been stuck for 2 days about where to put a certain bit of functionality, in A or B. Both seemed equally good (or bad). I had unit tests. I gave up and just kept my solution as is and went on writing the next bit of functionality. Halfway through I saw that the new code I was writing really made sense in B. So I moved it there. Ran my tests. Passed. Experiment and observe. Thanks Dave!
My aha! moment - The objective of the deployment pipeline is to prove that a change is not fit for production. I've been working with CI/CD for years and this is the first time I have heard this spin on it.
Yup! I think of it as a falsification mechanism. I can never prove that "All swans are white" but as soon as I see a black swan I know that they are not. I think that we can learn, and apply, a lot of the basic ideas of science to our advantage.
In other words: The purpose of testing is to break the system, the sooner the better. This is not excusive of CI/CD, it comes with testing since testing is a thing.
Hi Dave. Love all the content. I had a question around adding a new feature to an app using a cicd pipeline. If I am adding feature X, do I first need to add the QA/integration tests to the pipeline before I build the feature? If so, this will block the pipeline until the feature is built. What is the correct practise here? I ask because my team have found sometimes our QA tests lag behind the code for the feature, causing uncertainty.
Thanks. Yes my preference is to add the tests first, before any other development work on the feature begins. You avoid the problem of it not passing yet by not running this test as part of your pipeline until it is ready to pass. You can use it to guide development, but not use it, yet, a a regression test. My team used an annotation "@InDevelopment" for such tests, which would stop it running, but only for a period of time, unless renewed. So it would nag us if we forgot to turn the test on.
Hi Dave. I was wondering if you could make a video on doing continuous delivery with infrastructure updates. My team are currently struggling to marry updates to our application code to updates to our infrastructure code.
I think all my videos about CD are about doing CD with infrastructure updates, I don't make a distinction. The key idea is that you test them and they flow through the same pipeline as application changes. Thanks for the suggestion though, I will have a think about something that makes this clearer and goes into more detail. Meantime have you seen this old one: ruclips.net/video/so-xL0nmn0o/видео.html
Out of curiosity, since it irritated me: It's called Continuous *Delivery*, but *Deployment* Pipeline, even though (Continuous) Deployment would only be the next step. How come?
The deployment pipeline is definitive for deciding if a change is ready to be deployed into production, it doesn't mean that you have to take it's advice and do it continually.
You keep using this word like it means something VERY different than I understand it. When you say "commit", what are you talking about? When I say "commit", it' s the event of personal resolution that happens in the beginning of the project one time. I am commiting myself to accomplishing this task. In marriage seminars, some people need to more consciously commit to the marriage daily rather than entertain thoughts of quitting when things get hard. Either way, this commit is a personal resolution. There's nothing computerized about it. How do you "Hit Commit"? How does committing invoke automated processes?
"Commit" is a term used in software development to storing a change in a version control system. We are "committing the change". That means that we think it is good enough to share with other people. A version control system is a computer program that tracks each small change in software. It allows you to make progress in many small changes, many small "commits", and if you make a mistake you can take a step back to a place in the history of changes that you prefer.
@@ContinuousDelivery Since all my projects have been solo efforts, I have never used version control software. I would get to a "releasable state", copy the folder and break it again until the next new feature is added. Repeat.
lol all tests in our company seem flakey. feels like less than 1/4 of the time all tests will pass on develop or any PR where you have not broken anything.
Great! Should be essential viewing. So glad to finally have a source I can give to engineers which gets the fundamentals across concisely and clearly. Thank you!
Thanks Rob, I am pleased that you like my videos. More fun stuff in the pipeline :)
Ditto! +1
I had been stuck for 2 days about where to put a certain bit of functionality, in A or B. Both seemed equally good (or bad). I had unit tests. I gave up and just kept my solution as is and went on writing the next bit of functionality. Halfway through I saw that the new code I was writing really made sense in B. So I moved it there. Ran my tests. Passed.
Experiment and observe. Thanks Dave!
Great! it is always good to hear that my stuff has helped.
My aha! moment - The objective of the deployment pipeline is to prove that a change is not fit for production. I've been working with CI/CD for years and this is the first time I have heard this spin on it.
Yup! I think of it as a falsification mechanism. I can never prove that "All swans are white" but as soon as I see a black swan I know that they are not.
I think that we can learn, and apply, a lot of the basic ideas of science to our advantage.
In other words: The purpose of testing is to break the system, the sooner the better. This is not excusive of CI/CD, it comes with testing since testing is a thing.
Thank you, Dave!
Hi Dave. Love all the content. I had a question around adding a new feature to an app using a cicd pipeline. If I am adding feature X, do I first need to add the QA/integration tests to the pipeline before I build the feature? If so, this will block the pipeline until the feature is built. What is the correct practise here? I ask because my team have found sometimes our QA tests lag behind the code for the feature, causing uncertainty.
Thanks. Yes my preference is to add the tests first, before any other development work on the feature begins. You avoid the problem of it not passing yet by not running this test as part of your pipeline until it is ready to pass. You can use it to guide development, but not use it, yet, a a regression test. My team used an annotation "@InDevelopment" for such tests, which would stop it running, but only for a period of time, unless renewed. So it would nag us if we forgot to turn the test on.
@@ContinuousDelivery thanks for that. I will feed this back to me team :)
Hi Dave. I was wondering if you could make a video on doing continuous delivery with infrastructure updates. My team are currently struggling to marry updates to our application code to updates to our infrastructure code.
I think all my videos about CD are about doing CD with infrastructure updates, I don't make a distinction. The key idea is that you test them and they flow through the same pipeline as application changes. Thanks for the suggestion though, I will have a think about something that makes this clearer and goes into more detail. Meantime have you seen this old one: ruclips.net/video/so-xL0nmn0o/видео.html
Big fan of Dave have the book as well, but I have to say that background was incredibly distracting a simple black canvas would have sufficed
totally agree and was thinking the exact same thing
Thanks, and thanks for the feedback. I was trying to make something a bit more visually appealing than looking at me :)
Maybe just have the powerpoint(*) cycling through alongside without the background?
(*) I'm sure its something more exotic than Powerpoint?
Out of curiosity, since it irritated me: It's called Continuous *Delivery*, but *Deployment* Pipeline, even though (Continuous) Deployment would only be the next step. How come?
The deployment pipeline is definitive for deciding if a change is ready to be deployed into production, it doesn't mean that you have to take it's advice and do it continually.
You keep using this word like it means something VERY different than I understand it. When you say "commit", what are you talking about? When I say "commit", it' s the event of personal resolution that happens in the beginning of the project one time. I am commiting myself to accomplishing this task. In marriage seminars, some people need to more consciously commit to the marriage daily rather than entertain thoughts of quitting when things get hard. Either way, this commit is a personal resolution. There's nothing computerized about it. How do you "Hit Commit"? How does committing invoke automated processes?
"Commit" is a term used in software development to storing a change in a version control system. We are "committing the change". That means that we think it is good enough to share with other people.
A version control system is a computer program that tracks each small change in software. It allows you to make progress in many small changes, many small "commits", and if you make a mistake you can take a step back to a place in the history of changes that you prefer.
@@ContinuousDelivery
Since all my projects have been solo efforts, I have never used version control software. I would get to a "releasable state", copy the folder and break it again until the next new feature is added. Repeat.
lol all tests in our company seem flakey. feels like less than 1/4 of the time all tests will pass on develop or any PR where you have not broken anything.