Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-23T19:33:58.207Z
Answers: 2019-12-23T19:33:58.207Z
Answers: xtreampb
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-08T16:08:53.990Z
Answers: 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
Answers: xtreampb
Answers: CC BY-SA 3.0
Answers: 2017-12-31T12:13:28.790Z
Answers: 2017-12-31T12:13:28.790Z
Answers: 030
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-23T07:54:30.427Z
Comments: Could you indicate whether you solved the issue?
Comments: 030
Tags: <jenkins><continuous-deployment><build-pipeline><tfs>
Title: Build user for Visual Studio Online
UserDisplayName: xtreampb
ThreadText: # 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  
  
  ---
  
  