Please disregard now. It's all working fine. Someone changed the issues I was seeing in Jira yesterday and moved them to another release, incorrectly, at about the same time I was viewing them. I got the legacy aspect figured out as well so all of future configs should be non-legacy. Thanks.

hi Mark, great question. My team pointed me to your question; I actually talk on this topic quite a bit. DevOps is really just a buzzword, and everyone (including Inedo) is jumping on it to describe what we do. But ultimately, DevOps is a process improvement designed to improve release velocity (e.g. going agile) through two means: Automate everything you can Increase collaboration between teams Ultimately it's about improving a process of software release. There's a ton of noise about "best practices" out there, and everyone has opinions. But I think the best way to understand these opinions are to get a feel for the underlying process. Two suggestions for that. Release Management Done Right describes why you should be following a pipeline strategy. Source Control Done Right goes over how source control should/shouldn't be used, and is still quite relevant today (it was written before "DevOps" was buzzy). Now, based on your specific situation, my advice is to start simple. Just change-up your TFS version strategy a little bit -- don't build in each environment, but create a build artifact at the start. You can do this all in BuildMaster. The other tools are nice, but may not be necessary until you run into the problem of trying to have a single tool do it all.

One possible way is to still look up user's address from directory as a mandatory (to address), then option to provide additional email addresses (as cc). It can be considered additional behavior, not completely change of the logic. The send-email work-around is fine, the only thing is design the template from scratch is tedious, it'll be good to provide some default template and work from there.

There is no built-in variable function to do that, but it could be done with a custom variable function that does a lookup for the configuration variable based on the environment. Like $EnvironmentVariable(envName) or something. Let me know if you run into troubles, I can probably help! I don't know how easy it would be for us to generalize a lookup function, because there are so many different types of configuration variables (env, server, app, etc), and one might be desired for SErver, Role, etc.

Great question. First and foremost, if you haven't seen it already, take a read through KB#1056: A Comparison Between BuildMaster vs. Jenkins; it gives a good idea of the differences between release automation and continuous integration. Regarding your question ... What I don't understand is what is the advantage of having BuildMaster take over the pipeline with Jenkins doing the build instead of having Jenkins do it? ... it's really like asking, "what are the advantage of having a people-driven release process instead of having continuous builds automatically tested and then automatically deployed from source to production." The answer really depends on the organization. To many, the idea of continuous deployment is terrifying; for others, it's satisfying. What parts in the Blue Ocean screen shot would still be done in Jenkins and what would be done in BuildMaster? In this case, you would use Jenkins to create a release-suitable build; so your pipeline would look more like Build > Run Unit Test > Run Selenium Test > Export to ProGet > Pull into BuildMaster > Deploy to Integration. The "Deploy to Integration" would be triggering BuildMaster. Of course, Jenkins can deploy (or really, "do anything" since it runs scripts you write) -- but BuildMaster's deployment capabilities will almost always be superior. From there, BuildMaster would handle your release process, and actually get it to the proper environments securely, etc.

You could just bypass it on the promote page, by selecting "Do Not Execute" and then override the promotion status to Successful. That might be sufficient? Otherwise, we don't have a good way to evaluate whether or not a pipeline stage should advance. Perhaps one idea would to use a variable for targeting? or maybe a (JSON-only) option that says "skipStep" or something that you could have a $Variable as. Just ideas, not sure if they're feasible!

For my requirement at hands, simply having an option to include the notes as free text would do, as we won't be putting too much rich formatting notes inside, simply a reference number. Similar with "Additional Options" in Deployment Execution Completed event listener, if we could provide a checkbox to include Notes in Approval Required event listener should be fine for now.

Hello; this sounds like a NuGet/TFS question, I don't think we'll be able to help much. I would suggest to post to Microsoft forums or stackoverflow.

Hi David, I came across your post and noticed that you're experiencing an issue with Git source providers in BuildMaster. I understand that you're trying to use the "Get Git Source" command but can only get the source from the master branch. Based on the command you provided, it looks like you have the syntax partially correct. However, it seems that the code is being picked up from the master branch instead of the production branch that you specified. Have you tried specifying the branch name with the "refs/heads/" prefix? For example: bash Copy code Branch: refs/heads/PRODUCTION This may help in correctly identifying the production branch. Additionally, you mentioned that you have deleted the repo details from C:\BuildMaster_WEBTMP\SrcRepos, but are still facing the same issue. Have you tried clearing your Git credentials and re-entering them? It's possible that the issue may be related to authentication. Plus I was researching on Elmedia Player for Mac, and As someone who's been using Elmedia Player for Mac for quite some time, I can definitely say that it's a great media player that offers a lot of useful features. One thing I particularly appreciate about Elmedia Player is its ability to play virtually any video or audio format that you throw at it.

Tod - thanks for the reply. We would definitely be interested in this feature in an upcoming release. Thanks.

The TFS libraries used by the 4.9 and 5.x are different; sometimes, the workspace gets corrupted. To address this, it needs to be deleted on the server (unfortunately, deleting files on disk isn't enough). Please don't hesitate to contact support directly w/ any 5.x issues; it was a major upgrade, and while a lot of the changes were documented in various upgrade notes, we're quite familiar with common issues.

It would appear this isn't currently supported, you're right; we will add this in a future release!

Great idea; I've resolved this in [BM-2314] , and it will ship in next release of BuildMaster. Now it displays "AppName::DeployableName"

There are no built-in methods for this, but it could be done with a custom function or perhaps a powershell script that uses $ArtifactPath.

There might not be a single API call for this, but there is the Variables Management API (were you can get the variables data), or you could use the Native API to list the deployables.

I was finally able to reproduce this - I had been using v5.5.0 of the Windows extension which does not exhibit this behavior. We will have a fix for either the Windows extension, BuildMaster or both shortly.

If you upgrade to the latest v5.6 (currently 5.6.11), then it should work OK!

What you described should work; the connection should be proxied through the agent server you selected. however, I see you also submitted a ticket... so we'll review via that!

thanks for the report; the label should say "top-level items", not "everything".