Surfing in internet, i've found some interesting interview with Martin Fowler and Jez Humble, here is a link. Also there are guys who doubts about Continuous Delivery and Continuous Deployment practices, here is a link. Taking into account that i'm working in agile environment and we also have these painful release activities i decided to provide some comparison of what are these guys talking about and what we actually have in my project.
I can say that we haven't built a communism in this sphere. First of all we are not ready to release on demand, and this is the one of the main point of Continuous Delivery pattern. We still have problems in our culture such as keep all tests green, i will talk about it later. Because of business specific, constraints, security and finally complexity of the product we cannot automate everything. I think we have too bureaucratic process of several approves before release. The fact that we're offshore is also impose the fact that we cannot take part in release activity and also production health. And from technical point of view the architecture of the product is very complicated, there are a lot of external dependencies which we cannot automatically test, but only front to back manual testing.
Tests.
I really like the article testing-pyramid, especially the phrase "Where we also value that the information provided from the right matters to our customer and is rich in information, and the information from the left matters to our developers and their ability to be efficient." I've been a witness and also opponent in production issue judgement, when some guy asks, please point me some test that you have done for this User Story. So i just want to highlight that all test are valuable and you should automate them as march as possible.
The other issue that might cause you avoid acceptance tests and other complicated test is actually complexity of these tests. In compare to unit tests, they require more reliable interface, the should be understandable for other guys then IT, i mean BA and QA, and finally they should be produced by other guys other than IT.
So, while your software is evolved , your testing framework is also should evolve.
And final issue about acceptance test is actually maintenance. No doubt that it's rather harder to maintain acceptance test then unit test. First of all, you should wait much more time the result of these tests in you continuous integration system, because of the nature of these test. The second point is that the reason of the failure of such tests may be hidden under complexity of the flows under these tests. And this is the main problem of resistance of developers to keep them green
Ready to production code.
One guy reproached me, that using brunches is more efficient way to produce features in your software. But i would like to remind you what branches causes:
I can say that we haven't built a communism in this sphere. First of all we are not ready to release on demand, and this is the one of the main point of Continuous Delivery pattern. We still have problems in our culture such as keep all tests green, i will talk about it later. Because of business specific, constraints, security and finally complexity of the product we cannot automate everything. I think we have too bureaucratic process of several approves before release. The fact that we're offshore is also impose the fact that we cannot take part in release activity and also production health. And from technical point of view the architecture of the product is very complicated, there are a lot of external dependencies which we cannot automatically test, but only front to back manual testing.
Tests.
I really like the article testing-pyramid, especially the phrase "Where we also value that the information provided from the right matters to our customer and is rich in information, and the information from the left matters to our developers and their ability to be efficient." I've been a witness and also opponent in production issue judgement, when some guy asks, please point me some test that you have done for this User Story. So i just want to highlight that all test are valuable and you should automate them as march as possible.
The other issue that might cause you avoid acceptance tests and other complicated test is actually complexity of these tests. In compare to unit tests, they require more reliable interface, the should be understandable for other guys then IT, i mean BA and QA, and finally they should be produced by other guys other than IT.
So, while your software is evolved , your testing framework is also should evolve.
And final issue about acceptance test is actually maintenance. No doubt that it's rather harder to maintain acceptance test then unit test. First of all, you should wait much more time the result of these tests in you continuous integration system, because of the nature of these test. The second point is that the reason of the failure of such tests may be hidden under complexity of the flows under these tests. And this is the main problem of resistance of developers to keep them green
Ready to production code.
One guy reproached me, that using brunches is more efficient way to produce features in your software. But i would like to remind you what branches causes:
- Merging process. This process may be too long and painful
- You cannot guarantee the coexisting of several features in mainline on demand
- you cannot build continuous delivery pattern upon multiple brunches
Deployment pipeline
Well, this is an implementation of Continuous Delivery pattern. And IMHO it's strongly coupled with specific and architecture of the software. So any implementation of Deployment Pipeline should be flexible. May be it should have a pluggable architecture.
So thats all so far. I believe that it was interesting for you.
No comments:
Post a Comment