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.

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.

Solution found, wrong app pool user. thks all

The easiest option would just be to use the PowerShell Agent, which does not require any installation and simply uses remote PowerShell. However, if you can't use this or don't want to due to performance issues, you can manually install the Otter/Inedo agent by downloading the manual install package for the latest version of Otter here: http://inedo.com/otter/versions The instructions for installing the agent manually can be found here: http://inedo.com/support/documentation/otter/installation/manual

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

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.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

Thanks Philippe, looks like you identified the bug and workaround. It will be addressed as OTTER-119

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!

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.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

Did you change the name of the branch after cloning? When cloned, branches should automatically track the remote branch. One option is to navigate to the local GitRafts directory in the Execution.DefaultWorkingDirectory path (found in All Settings), and delete the local workspace and try again. If you have git installed on the same server as Otter, you can manually configure the repo to track the remote branch using the commands outlined here: http://stackoverflow.com/a/2286030

A License Key is always required. You can get one from My.Inedo.com. The ProGet Silent Installation guide gives the arguments to the installer; one of the options is to automatically request a key (just set Edition to Express or Trial).

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.

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way. It was a discussion related to Jenkins so I may have misunderstood where the change was.

Restating the Proget's service fixed the problem! Thank you for your rapid response :) Regards.

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

You can just drop your npm packages in the configured drop folder; they need to be valid npm package,s which means <name>-<version>.tgz file format.

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.

Uh, my current extensions path is C:\Program Files\ProGet\Extensions, not ProgramData. It's the Extensions.ServiceTempPath and Extensions.WebTempPath paths that are empty and ProGet is warning about. Here are the settings: [image: HCPtEyc.png] And the warning: [image: EUzrmf6.png] So now there's even more confusion. Should I move the Extensions directory from Program Files to Program Data? What about the ServiceTempPath and WebTempPath?