HTTPS clone URL
Subversion checkout URL
- 11 1 Deployment Test Plan
- 11 15 Deployment Test Plan
- 12 20 deployment test plan
- 12 6 deployment test plan
- 2 28 Deployment Test Plan
- 3 21 Deployment Test Plan
- 3 7 Deployment Test Plan
- 4 4 Deployment Test Plan
- API v3 Specification
- Hosting the NuGet Gallery Locally in IIS
- Iteration 5 Test Plan (12 6 Deployment)
- Package Metadata in the NuGet Gallery Feed
- Revamping Package Owners Account Management Experience
- Tab Completion API Endpoints
- Test Plans
- Tracking support requests
Clone this wiki locally
Here are the branches we used to develop the gallery.
Topic branches are the branches in which work is done. They should be named with the Issue Number clearly visible (for example: "Bug-1234"). Including your username also helps to identify who "owns" that branch. All work must be done in topic branches. Topic branches should live until the feature is deployed to Production. Once deployed, the topic branch can be deleted.
Topic branches should ALWAYS be merged using non-fastforward merges. The reason for this is that it effectively "collapses" your commits down to a single entry in the main branch, allowing it to be easily removed if we need to take it out of a deployment.
This branch represents the starting point for an iteration of dev work. All topic branches should be created from this point. It is essential that topic branches start from here to ensure features remain as isolated from each other as possible and to allow them to be easily removed from deployments when test issues arise.
This branch represents the merged content of the feature work devs are working on. It is the plan for the next preview deployment. However, since topic branches should remain alive, this branch can be easily discarded and rebuilt from
dev-start and a collection of topic branches in order to remove features from a deployment.
master branches represent the code on "preview.nuget.org", "staging.nuget.org", and "nuget.org" respectively. They should always be advanced using fast-forward merges.
Sometimes issues will arise during integration testing and fixes will need to be made directly to one of the integrated environments. If that needs to happen, follow this process:
- Create a separate issue for the fix (even if there is one for the feature in which the bug has arisen).
- Create a topic branch off of the deployed branch in question (i.e.
preview) for that issue
- Make the fix
- Submit a pull request against the deployed branch
- Merge the fix in to the deployed branch via a non-fastforward merge
- Merge the fix in to
devvia a non-fastforward merge
Occasionally the fix will be small enough and urgent enough that we can't/don't want to wait for a code review before merging in to the deployed branch. In this case, merge directly into the deployed branch and send a pull request to merge the change in to
dev. That way, we can do the code-review on the less-urgent process of merging in to