0

I am building a VSTS build pipeline for continues integration and deployment of a MVC web project. My client wants 0 down time in case of continues deployment so we have considered restructuring the source control strategy and split the single code repository to following:

Core features

  1. Feature 1
  2. Feature 2 .....
  3. Feature n

We are planning to keep features as child branches of Core feature and place individual build templates for each of the branch and sub-branches. So the ideal scenario is that if there is any change in core feature branch, the build should be deployed with full code ( branch + sub-branches) but if only 1 feature branch is changed, the continues deployment will be executed only for that branch or the feature in the branch.

So the questions which need some guidance are: -

  • Is the idea of feature branching is fine and can be used on production?
  • The .Net MVC application is n-tier application which has web tier, service and repository tiers. Shall I split the service and repository layers also in the core and feature branches to make it separated?

  • If I split the service and repository, how should the communication happened between the different features:

  • Via service to service calling? Like if feature 1 requires some functionality of feature 2, the feature 1 service calls feature 2 service and merge the result to send it to feature 1 GUI?

  • Feature 1 repository calls feature 2 repository, but this approach will bring dependency of feature 1 on feature 2 means if feature 2 is down at the time of deployment, feature 1 is also experience errors.

  • Splitting repository to several features is a good idea?

Thanks

Rupendra
  • 548
  • 2
  • 10
  • 35
  • Be very careful about terminology. The way you use the term "feature branch" isn't the way it's commonly used in the industry. A feature branch is for isolating development of a new feature, not for managing ongoing long-term development of different application components. – Daniel Mann Jul 27 '17 at 16:04
  • @Daniel Mann , agreed with your comment. But the other known terminology I know is sub-module source control approach which is I guess reserved for GIT source control. Could you suggest any such name which fits best with the question? – Rupendra Jul 28 '17 at 04:02

1 Answers1

0

Splitting repository to several features is ok, because they could be used in other apps (e.g. mobile app)

I recommend that you can consider VSTS Packages feature or other 3rd package feed. The workflow:

  1. Push changes to server > Trigger CI build> Pack and publish package to VSTS feed by using NuGet task
  2. Install necessary packages to the web project and coding.
  3. Push changes of web project to server > Trigger CI build with current installed package (Do not update package)
  4. Update necessary package to the web project for new feature
  5. Push changes of web project to server > Trigger CI build
starian chen-MSFT
  • 31,056
  • 2
  • 22
  • 47
  • this answer is not related to the question, I guess you should read the question once again. – Rupendra Jul 27 '17 at 06:35
  • Too many questions in this thread, but they are related to separate repository, my point is using package management and update the package if related project need to work with new feature. what are you confused? Could your provide the sample to explain it? – starian chen-MSFT Jul 27 '17 at 06:48
  • We are already using package management using Nuget feeds. The point here is to get suggestions about how to split services, repositories and the way inter service communication should be made after splitting it to achieve partial deployment using continues deployment process. even if we use repository as packages, changing a package would have require for a down time for all those services for which the repository is being referenced. am I right? – Rupendra Jul 27 '17 at 07:14
  • You can deploy them together in a environment of release. There isn't the built-in feature to check which artifact is changed, you may check it through the version (e.g. assemblyinfo.cs or other) by using PowerShell before deploy app task, the deploy task can deploy app per to condition: [Specify conditions for running a task](https://www.visualstudio.com/en-us/docs/build/concepts/process/conditions) – starian chen-MSFT Jul 27 '17 at 07:32
  • let me try this and get back to you in next week to see if it works, thanks – Rupendra Jul 27 '17 at 07:54