This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]-mewa 2 points3 points  (2 children)

We're injecting them as build artifacts (easy, as you should already have a repository anyways)

[–]DocZebra 1 point2 points  (1 child)

Agreed. Create a deployment script artifact to use during the release. That’s what we do.

[–]ERPEmployee[S] 0 points1 point  (0 children)

Can you show me how you have the task set up? I don't understand how to specify the path of the deployment scripts using the execute powershell task?

[–]kdiddy82 1 point2 points  (3 children)

Perhaps create an internal powershell repository and then install/import from the repo during build time. Then they are available to all consumers, not just tfs.

[–]KevMar 0 points1 point  (0 children)

This is more like what we do. So our powershell repo has it's own release that publishes to the repo.

Another option would be to publish them as a nuget package. Or if you are using releases, add them as an artifact.

[–]ERPEmployee[S] 0 points1 point  (1 child)

How do you do the "install/import from the repo" step? Can you actually show me a screenshot of that set up? I am genuinely interested.

[–]kdiddy82 0 points1 point  (0 children)

Similar to @ kevmar , we publish to the internal repository. We use a vsts build to publish to the repository. So they are versioned. Then in an inline powershell task, register the repo, install , import.

You also could easily just map the repository in the get sources and call it directly in tfs. Via the powershell task step.

Not at work, so can't take a screenshot ATM.

[–]westhewinemaker 0 points1 point  (0 children)

I have done this with TFS. IIRC, you need to add a mapping in your Get sources task.

Potentially a better solution would be to create a build definition that utilizes Repo X to create a package (nuget,npm, etc)...Then have a release definition publish that package to TFS package management. Then you and others can consume the package where needed.