Version control and website branching

We have a version control (SVN) web application. The boot always contains the latest good version of the website.

I would like to hear how other teams manage multiple versions of the same site and how do you publish different versions for UAT, testing, bug fixing, improvements, etc.?

Let's say our business users come together and they need a new cheat sheet feature ... So what we do is a new branch for our developer. How should I post a branch without affecting the main dev site. Should we publish each branch of the website in unique ports?

http: // DevServer: 80 = Trunk
http: // DevServer: 8081 = branch 001
http: // DevServer: 8082 = branch 002
http: // DevServer: 8083 = branch 003
http: // DevServer: 8084 = branch 004

Obvisouly we also have to deploy project files to unqiue directories and configure IIS correctly ....

Is this a common method? What are the best practices?

+4
source share
3 answers

Ideally, you should run a separate machine for each environment (production, uat, test, dev and ci). If you do not have resources for real physical machines, then virtualization is the way to go for non-production environments.

It also means that you can correctly test the effects of the various dependencies and libraries that you use.

EDIT: About branching ...

What we do here, and in several places that I worked with before, has an integration branch from the trunk. Developers developing new features move away from the integration industry and reintegrate into the integration industry. CI is performed both by integration and by trunk. Unofficial testing can be done during integration, but more formal testing (UAT releases) comes from the trunk. Periodically, we integrate down from the integration branch into the trunk. This has the added benefit of protecting the barrel.

i.e.

trunk integration feature1 feature2 
+6
source

The RedBean book (free) provides an excellent description of branching. Although the book is intended for SVN, the description of the branching strategy applies to everyone.

Another good free resource is the Microsoft Team Foundation Server Branching Guidance . It combines:

  • Parallel development
  • Branching defined
  • Creating Isolation in Team Foundation Server
  • General Branch Structure Guide
  • Branching strategies
  • Wide areas of branching insulation
  • Creating your branching strategy
  • Defining a code promotion model.
  • Member Crews: How Microsoft Does It
  • End-to-end deployment scenario
+1
source

To deploy different branches to different ports, this is one of the solutions; in the Java servlet environment, the decision to map branches in different ways will be easier (I do not know if this is true for IIS):

Both solutions should work well. If I would not choose any other requirements, a solution that is easier to configure and maintain using the technology used.

+1
source

All Articles