<p>A separate build user was used so that all tasks that are performed by the build system has an account to preform them with.  This way teams can still approve for releases to be deployed, but the build account is the account with the permissions to access the targeted environments.</p>

CC BY-SA 4.0
2019-12-23T19:33:58.207Z
2019-12-23T19:33:58.207Z
xtreampb
<p>In my opinion, there should always one key per user:</p>

<ul>
<li>Security: If an employee will leave the company then the key could be revoked and the person who left the company cannot trigger builds anymore</li>
<li>Access-control and responsibilties: developers from team b are allowed to deploy apps to the production environment of team b, while members of team a are responsible for their own app and are restricted to environment a.</li>
</ul>

CC BY-SA 3.0
2018-02-08T16:08:53.990Z
while I agree with your points, our development isn't broken into teams with individual responsibility.  At some point everyone will need to work on every project.  The only people 'approving' a release is the product managers, who can only approve builds that the QA team approves, which will only get builds that the dev team submits through triggering a build and approving it in their sandboxed test environment

as point 1, i'm unable to revoke individual PATs as they belong to the individual user account and they create them. Reason for the build account that sys admin/devops manages
xtreampb
CC BY-SA 3.0
2017-12-31T12:13:28.790Z
2017-12-31T12:13:28.790Z
030
<p>Using visual studio online, do I need a separate user for the purpose of ferrying code/builds across machines.  I understand that the built in service account builds code and can publish, but with things like Jenkins that require access tokens to retrieve source code (for projects like unity (no we are not able to use unity build)) I find it would be best to have a 'service' account where I can create personal access tokens that isn't tied to any one developer.</p>

<p>Do I need a 'build' user or is there another way to ferry code to Jenkins servers or using personal access tokens for deployment groups?</p>

CC BY-SA 4.0
2019-12-23T07:54:30.427Z
Could you indicate whether you solved the issue?
030
<jenkins><continuous-deployment><build-pipeline><tfs>
Build user for Visual Studio Online
xtreampb
# Build user for Visual Studio Online

(Asked by: username_0 on 2017-06-21)

Using visual studio online, do I need a separate user for the purpose of ferrying code/builds across machines. I understand that the built in service account builds code and can publish, but with things like Jenkins that require access tokens to retrieve source code (for projects like unity (no we are not able to use unity build)) I find it would be best to have a 'service' account where I can create personal access tokens that isn't tied to any one developer.

Do I need a 'build' user or is there another way to ferry code to Jenkins servers or using personal access tokens for deployment groups?

**Tags:** jenkins, continuous-deployment, build-pipeline, tfs

> **Comments:**
> **username_1**: Could you indicate whether you solved the issue?  

---

## 2 answers

### Answer by username_0 on 2019-12-23. Score: 0 | Accepted answer

A separate build user was used so that all tasks that are performed by the build system has an account to preform them with. This way teams can still approve for releases to be deployed, but the build account is the account with the permissions to access the targeted environments.


---

### Answer by username_1 on 2017-12-31. Score: 1

In my opinion, there should always one key per user:

* Security: If an employee will leave the company then the key could be revoked and the person who left the company cannot trigger builds anymore
* Access-control and responsibilties: developers from team b are allowed to deploy apps to the production environment of team b, while members of team a are responsible for their own app and are restricted to environment a.

> **Comments:**
> **username_0**: while I agree with your points, our development isn't broken into teams with individual responsibility.  At some point everyone will need to work on every project.  The only people 'approving' a release is the product managers, who can only approve builds that the QA team approves, which will only get builds that the dev team submits through triggering a build and approving it in their sandboxed test environment  as point 1, i'm unable to revoke individual PATs as they belong to the individual user account and they create them. Reason for the build account that sys admin/devops manages  

---

