Multi project soutions, packaging and OpenTAP development

OK, when OpenTAP was released I was already familiar with the framework and test concept - thanks @jeff.dralla for thinking I was a competitor spy., which I took as a compliment btw.
IMO, once you’ve created something with OpenTAP there’s no going back. A colleague mentioned the other day how they can blah, blah, blah in 5 minutes without having to learn yet another test automation framework. I probably couldn’t convince them, and they called it a YATAF. Quickly switching into defence mode and getting the hump about the ‘yet another’ jibe about my new beloved best framework, my retort was OpenTAP is TOTAF - the only test automation framework. We were well into the acronym spouting, religious-like arguments engineers get to when ‘discussing’ stuff. So, I realised a better acronym is needed to describe what OpenTAP is to the non-believers. Suggestions welcome.

Dragging myself back on topic, once the development with OpenTAP starts to flow, it is suited to rapid development and large complex projects. My issue is that as a small developer with no formal computer science training I’ve never really collaborated with more than a couple of other developers, and we tended to keep things pretty simple. Now I like simple, but I think there is ‘simpler’ and best practices, and I think I’m missing something.

I’ve started to look at packaging and how to distribute the code within an enterprise, collaborate with others and automate some tasks using devOps.

At the moment:

  • Multiple projects are under a single solution.
  • All projects build to a single dev folder or release folder.
  • A package is created from the release folder and distributed from a shared network drive.

That’s all good, but I know it can be better, even without implementing a CI/CD strategy.

So I was curious what other developers do?

  1. Do you build to a single folder or to each project bin folder. and why?
  2. How do you use packaging? Do you pick up the dll from the project’s bin/debug | bin/release folder?
  3. How to you you make your package available?
  4. Should the package.xml file be stored in the repo with the project/solution?
  5. It was very simple to create a bundle package using ./tap package create -v ‘.\Packages\SDK\Dev\release_package_config.xml’ , but how difficult and time-consuming is this for a multi-project solution?
  6. How to get VS to create the bundle package at the of the release build?
  7. Should I look at moving to GitLab. How do I convince management, and is there a cost?

Something to kick off a conversation that has often kept me awake at night, sad I know.

My solution explorer:

4 Likes

Nice use of acronyms :grinning_face_with_smiling_eyes: I won’t claim to follow up-to-date best practices, but here are my answers:

  1. I build all projects to the same output directory that TapPackages install to:
    C:\Program Files\Keysight\Test Automation\MyApplicationName

  2. The packager picks up dlls from the same location as answer #1.

  3. I copy the TapPackage to a network share folder, which the entire lab is pointing to as a package repository.

  4. My package.xml is indeed version controlled along with the source code.

  5. I have a solution (.sln) with multiple projects (.csproj). But only 1 project has a package.xml file, and that package.xml file includes the dlls from every project. That way a single TapPackage contains all my projects.

  6. I use this task in the csproj file to perform packaging in Release config.

  <UsingTask TaskName="Keysight.OpenTap.Sdk.MSBuild.PackageTask" AssemblyFile="$(TAP_PATH)\Packages\SDK\Keysight.OpenTap.Sdk.MSBuild.dll" />
  <Target Name="AfterBuild" Condition="'$(Configuration)' == 'Release'">
    <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
      <Output TaskParameter="Assemblies" ItemName="TargetInfo" />
    </GetAssemblyIdentity>
    <PackageTask Dir="$(TAP_PATH)" ConfFile="$(ProjectDir)\package.xml" />
  </Target>
  1. I use GitHub. GitLab seems pretty cool. What VCS are you using now?

MTFBWY

2 Likes

DOH! I actually had to look up MTFBWY cos it’s not May 4th…what’s life without a good acronym?

Nice approach.
So, does the project with the packaging.xml have to be the last project built?

I’m using git on devOps.

@jason.hicks LOL :laughing:

Good question. I believe you’re right, the project with package.xml should be the last one built. That’s how my solution is set up, though I hadn’t thought about that for some time. Wouldn’t want old dlls getting packaged.

1 Like

Right, because the Project with the package.xml file defines which DLLs to include in the .TapPackage file, you will want to build that last so that all the latest DLLs are being pulled in.

@jason.hicks to answer some of your original questions:

  1. This is generally user preference, but I would say most often I see a single bin folder, mostly for convenience.
  1. If you haven’t seen it already, there is a good section on Packaging plugins here: OpenTAP. Generally it is not needed to create a .TapPackage with debug builds (just use the DLLs directly), only release builds.
  1. Most people seem to use a network share. You can actually configure the Network Share as a location for the Package Manager to search in your Package Manager settings. Of course we have the public packages.opentap.io page for anything that you believe could be generally useful and want to distribute. We have had some discussions of making the Package Repo available to self host. Is that of interest to anyone?
  1. Yes, definitely I recommend storing the package.xml with your project.
  1. It is still fairly easy. It can be done as part of your release build. And you can add dependencies on other plugins as part of your package.xml as well.
  1. This should happen automatically if you are using the Plugin Templates just by defining you package.xml file
  1. The OpenTAP team loves Gitlab, and that is where we publicly host our code. Your code does not have to be open source to be hosted on Gitlab, it is possible to create private projects. It is free to host your code, but there are additional paid features like security scans, time on build runners as part of CI/CD, etc. To be transparent, this all applies to GitHub as well. In general, I think transitioning to one of these tools and turning on a CI/CD process is well worth it, and you will likely find it easier than you expect.
2 Likes