Harassment: ASML, STI assisting with release management

Thu, Feb 20, 2025 ❝STI department enjoying an oppressive role in application integration and releases❞

Contents

Now, this is a rather interesting topic. STI is a department that is supposed to assist developers by tackling integration and release work. However, this turns out in practice, to contain a significant proportion of “policing unit” in terms of interaction with development teams.

This article essentially adds onto Interim: manual builds and continuous integration.

Introducing STI

STI, “System Test and Integration”, is a separate department that tackles system-testing and integration. Though, it is somewhat more limited use for the desktop applications, them being stand-alone products.

After the initial work of setting up and automating the builds as described in the referenced post, when it was possible to run an automated build and have it do most of the work, the (dubious) idea came to have STI take care of it. Now, the part that had me concerned is that this meant that a different department thus another process involved and more alignment.

STI doing integration and release builds

For context, as developers had direct access to the build files, they could extend the build (for their tools) as needed. So, by the time STI took over the integration and release process, the CI/CD pipeline was still quite a bit less comprehensive.

STI doing integration and release builds, essentially meant more indirection in communication, people who didn’t know how the build tooling worked and had to come back for further assistance during a significant transition time. Around sprint ends, it meant that we would need to have work ready for integration by a certain time and it had to build and merge with the main development branch. Then a team would hope they were one of the first to integrate, because merge conflicts occurred, they would not be resolved by them. (This is not wholely unreasonable, but it adds significant complication when a whole different department is already involved.) When there were complications, STI would come nagging. If they weren’t happy about it, you’d get the occasional threat of being pushed to the back of the line. This becomes increasingly relevant when 10+ development teams rely on STI to do the integration.

I have on occasion enjoyed the threats of STI, then afterwards been asked to assist them because they don’t have enough experience to make changes to the build environment. I was asked because I had set up a non-neglible part of the build thus also had the knowledge at hand. Unfortunately, that appreciation never seemed to reflect in other interaction with STI for the team.

Note that I was asked easily 6 or 7 times more to assist or instruct on technical matters concerning builds, simply because I was well aware of how the process was set up and was familiar with most of the maven and plug-in configuration, at least for desktop applications.

Another disadvantage of having a separate department that is for a large part, just “running” the processes, it is not a one-time handover of work. It becomes a back-and-forth interaction with multiple departments involved. And on top of that, STI gets to take on this “it doesn’t work, fix it!” attitude and throw back the work because of issues. They did not always approach it with this attitude, but we are unnecessarily dependent on a department that doesn’t have the competence to make much of changes so it creates an “unfortunate” kind of necessary cooperation.

STI “integrating” then all-at-once build

At first, STI integrating the work of different teams meant: one-by-one take team branch submitted for integration, merge if possible otherwise throw back at team, continue with next team. After all submitted integration work was merged (of those that were mergeable without conflicts) they would run a build and if that failed it was again up to developers to figure out. Later, when there was better control, they would have some intermediate builds. However, as they aren’t developers, any relevant issue meant pushing it back to the respective teams.

STI speeding up integration testing

Now, to some extent STI was handling integration testing. It should be taken into account in this story, that the desktop applications had a significantly smaller stake in this. They eventually did put effort into improving the time needed for integration testing to noticably significant degree, although them being non-developers it usually meant turning off tests that they deemed “not that relevant” based on some test execution information like coverage. Again, to our work it was a nice plus if we got faster feedback for a complete build, but it wouldn’t much (if at all) impact our area of development work.

Too much attention/influence?

After having contributed significant part of the build, having the process then off-loaded to STI, wasn’t ideal. I didn’t consider it at the time, but given what I now know about the PO (yet another story), I have to consider that off-loading the release process was an effort to reduce my influence and the impact I could have among collaborating teams. I did start to get some familiarity, having helped several teams with git on multiple occasions with proper explanations and assistance for the commandline tooling (e.g. with merges, in case the need arose for rebasing, and other more complicated operations), and the improvements to the build, my familiarity with the early build and release-procedure and installer, and not unlikely my ability to interoperate and align with the various teams.

STI from then on

STI, from then on, continued to be a (enforced) necessary component in the development of products. This became more problematic during the last months when multiple iterations of (almost) department-wide efforts governed by the SAFe, consisting of 12+ teams working on a common end-goal in essentially a large-scale project with multiple departments apart from development involved and easily 10+ development teams planning work. Now, I have no particular criticism about SAFe. I think SAFe worked reasonably well for this scale of effort, and complications that arose are often the result of certain departments trying to cut corners or misunderstanding (consequences of) the process.

For example, STI would consider it “practical” to demand delivery at a specific moment in time for each team. Taking essentially zero time for possible anomalies and incidents. This is undoubtedly beneficial to ass-kiss with management and other departments, but is not realistic in practice. However, to some extent, they have the benefit that in many cases they can just pass failures back to dev-teams anyways.

STI member “threat”

In the last week, one of the last days, one member of STI “found” me and bothered to tell me that “His manager trusts him, and my manager doesn’t trust me”. I didn’t know what to think of it at the time, but this is without a doubt part of this same ongoing harassment campaign that was already long underway while at work in the department.

update He may have used the term ‘believe’ instead of ’trust’.

Note that one member in particular was always the most problematic one, including posing the statement above. Others were annoyingly inflexible at times, but is largely enabled by the opportunistic position STI enjoys in the over-all process.

Changelog

This article will receive updates, if necessary.

• 2025-02-20 Update to comment on an uncertainty.
• 2025-02-20 Initial version.