In a way, true! We shouldn't be needing version numbers when we are continuously integrating ONLY the working software and are ensuring that each time we commit, by running all the tests that are written in and over the periphery of the entire project. However, when we say, each commit is a deploy too, it might mean just that all the working code is being deployed onto a staging environment and while running the continuous build process the tests that ran didn't use the actual environment, which is very widely the case. Of course, each successful build might be replicated over to the production environment, but would you still consider doing that when your final delivery is due at the end of current iteration or sprint? In my view, deliver when done, might not necessarily mean that you gotta deliver it immediately upon commit if the project is still under "development from scratch" phase as opposed to an "enhancement/maintenance" phase. What say?
but would you still consider doing that when your final delivery is due at the end of current iteration or sprint?
What I'm talking about does not have the artificial boundaries of iterations and releases.
In my view, deliver when done, might not necessarily mean that you gotta deliver it immediately upon commit if the project is still under "development from scratch" phase as opposed to an "enhancement/maintenance" phase.
Thats exactly the sort of mindset I'm talking about and it might feel a little uneasy at first, but I think we can get there.
I would think, crisis handing, might be a difficult task if something unpredictably nasty becomes part of your production environment if the deployment was really as eager as that. Another thing, would you suggest that the QA/UAT takes place on the live deployment? If yes, would the project team be all-the-time ready to handle any major shortcoming (say, a functional bug) that managed to make it through the build? If no, shouldn't we allow some time for QA before it all reached production?
Delivering in a continuous flow does not mean that you can't have a tiered deployment model where on one of the tiers you can run an exhaustive set of tests. Without the safety net of tests (both unit and functional) you won't be able to deliver in a continuous flow.
4 comments:
In a way, true! We shouldn't be needing version numbers when we are continuously integrating ONLY the working software and are ensuring that each time we commit, by running all the tests that are written in and over the periphery of the entire project. However, when we say, each commit is a deploy too, it might mean just that all the working code is being deployed onto a staging environment and while running the continuous build process the tests that ran didn't use the actual environment, which is very widely the case. Of course, each successful build might be replicated over to the production environment, but would you still consider doing that when your final delivery is due at the end of current iteration or sprint?
In my view, deliver when done, might not necessarily mean that you gotta deliver it immediately upon commit if the project is still under "development from scratch" phase as opposed to an "enhancement/maintenance" phase. What say?
but would you still consider doing that when your final delivery is due at the end of current iteration or sprint?
What I'm talking about does not have the artificial boundaries of iterations and releases.
In my view, deliver when done, might not necessarily mean that you gotta deliver it immediately upon commit if the project is still under "development from scratch" phase as opposed to an "enhancement/maintenance" phase.
Thats exactly the sort of mindset I'm talking about and it might feel a little uneasy at first, but I think we can get there.
I would think, crisis handing, might be a difficult task if something unpredictably nasty becomes part of your production environment if the deployment was really as eager as that.
Another thing, would you suggest that the QA/UAT takes place on the live deployment? If yes, would the project team be all-the-time ready to handle any major shortcoming (say, a functional bug) that managed to make it through the build?
If no, shouldn't we allow some time for QA before it all reached production?
Tell me if I am getting too verbose ;)
Delivering in a continuous flow does not mean that you can't have a tiered deployment model where on one of the tiers you can run an exhaustive set of tests. Without the safety net of tests (both unit and functional) you won't be able to deliver in a continuous flow.
Post a Comment