Implementation For larger infrastructure

[hepsi204]

• Azure Key Vaults used to store secrets
• Azure Devops Service connections used to authenticate pipeline agents instead of saving Azure Service principle in Devops library as a variable group
• Pipeline stages, parameters and AzureCLI tasks used
• JMeter properties files used to:
  • make load profile flexible
  • enabling multiple test environments
• JMeter worker count made configurable so it can be set via pipeline
• Azure Backend Listener plugin has been added to the Dockerfile

[ghost]

All CLA requirements met.

[allantargino]

Hello @hepsi204 ! Thank you so much for this wonderful work, congratulations for putting together such great example!

I have some considerations about it. I think we may need to break it into different PRs with different purposes:

What I believe we should take, break and accept:

• Key Vault implementation: I loved the idea of adding it to the sample. It definitely makes it more secure. I created #30 for that.
• Azure Devops Service connections. We can address it in the same PR that solves #30.

What I believe we should just add as documentation:

• Azure Backend Listener plugin: the reason why is to keep Dockerfile as simple and as generic as possible for any future user. Not everyone will use this plugin, so we shouldn't add it directly do the Dockerfile. On the other hand, we can write a markdown file and add it to the docs folder explaining not only how people install it, but also how they can use the plugin. I see A LOT of value on this doc. We already have #18 open for that.

What I believe we shouldn't introduce now:

• JMeter properties files: for the same reason of keeping the sample simple. If you check the main README file, you should see some instructions in the end on how to make it more flexible: If you feel that more is necessary, how about a documentation on the docs directory explaining how to do it?
• A different directory (ImplementationForLargeInfrastructures) just for this alternative change. I think we should work together in a single implementation to avoid code duplication. Makes sense?

What I would like to ask you:

• Pipeline stages. Do you feel that breaking into separated stages gives us any advantage? Or does it add complexity?

I would love your thoughts on these topics! Again, thank you so much! Let's work together to introduce all the great changes you are proposing!

[allantargino]

@hepsi204 I marked it as a Draft PR so we can iterate on it :)

[hepsi204]

Hi @allantargino ,

Thank you for getting back to me so soon and the kind words. :)

I needed to bounce ideas off you all to decide what to keep/drop hence I added the entire implementation as a separate folder as this is my very first open source PR, so your feedback is perfect.

I also think all the points made were good points.

What are your thoughts on making JMeter slave counts configurable as parameters so users can choose number of slaves to initialise ? - keep/drop ?

I will get started on breaking the work into PR's.

Thanks, Hepsiba Reddy

[allantargino]

Hi @hepsi204! I am sorry it took so long to reply you back now!

I think that having that as a library variable makes the experience easy for me. Do you think that it's best to have it as a parameter inside a template?

[allantargino]

I didn't intend to close this, sorry! I deleted the master branch in favor of the new main one and didn't realize this PR was in draft. But I think most of the code is being iterated on #33 right? Feel free to open this again (and target the main branch).