It is late, I was asleep, but I woke up and started a thought on this issue I believe I have had with my communication.
My title is Software Test Engineer (STE), the work I do daily has been a mix of that and Software Development Engineer in Test (SDET). I have worked directly with a few devs in a dedicated fashion. More recently I've been driving not only the test software design and approach, but incorporating the CD portion of a CI/CD pipeline (lets not get into what I mean by Continuous Delivery right now).
Here has been my mistake: I've been communicating under the assumption that everyone knows I sympathize with the challenges they face and the work I'm doing (which isn't always ideal) is actually what I as a developer want, not what I want developers to do for me as an STE. See I would like to go into details about the push back I've gotten and thus provide this post with the relevant context as to why developers would be against CI/CD... but that would go further into the historical operations of the company and if done wrong you would misunderstand reading it. Let me try anyway.
The historical process has been, devs start their work, they finish the initial work which includes whatever amount of testing they deem necessary and send it to a team to install to environments for QA to test against. With the CI/CD based pipeline there is an environment installation step along with integration tests managed by the QA team. When a new project is started there is a set of modifications to make the pipeline function for the environment's of the new client project (Each client gets a heavily customized product off a base platform). Here is the challenge, the developer is under pressure to get a release out but the pipeline didn't come setup for free and doesn't completely execute without some additional work.
Remember that communication mistake, see my expectation is that the pipeline is useful and the developer will pull in the time and resources to make the pipeline function... what I didn't count on is the CD portion of that pipeline is categorized as a set of steps beneficial to QA and not relevant to development work. The result, delete those pipeline steps to get the release out the door. Remember I prepped you, if I didn't do a good job you'll misunderstand this last statement, how can a developer say that the release is ready to go out the door when their pipeline is failing? Yep, that is my first impression too, along with... why is the STE taking a build which doesn't pass pipeline? But again, the CD portion isn't the developers pipeline portion it is perceived as the steps some Test Engineer is adding to make their life easier.
Let me jump back now to the "not ideal." Have you ever heard of the distributed version control system? It has had much criticism from those using centrally controlled version system as not being necessary because generally you don't need to manage equally legitimate trunks of the same source base and it is much better to have a single source of truth. Well our product is exactly that, a base state where many trunks diverge in the wood and we all maintain them separately, it is the ideal situation for a distributed version control system to help manage the commonalities.
Continuing, we also have an old product. Yes we develop new products and features daily but we aren't starting with nothing, we live in a Microsoft code base and thus are not poised to just jump into the new CI/CD world of Docker and Kerbernetes. This means when developing the pipeline I don't have access to an environment management system GitLab expects, but I can still build it out and get a good chunk of the benefits even though this approach is not supported. So the developers can fork from the base and get a working pipeline, but to stand up a new environment and run the complete pipeline against it requires a number of configuration and software installation to setup. It also means the environment is not clean and deployment and test steps can run in parallel against the same environment. Remember I said not ideal, but from my developer perspective it is still worth it.
Top comments (1)
My only guess is that the build/deploy setup feels like drudgery to most people and do not want to invest their brain power in perfecting it. I ran into this time and time again with teams where their application receives all the love. This might be on the business to better communicate the value of this activity. Totally agree a lot of bugs come from a bad pipeline.