4

I have a project with .net core web api backend and angular as front end.

I have single repository for both the projects with front end and backend in their own separate folders.

I have written pipeline in azure which builds both front end and backend in two stages whenever anything is pushed to the repository.

Now in the release when I deploy the code it also deploys both front end and backend no matter if only backend is changed or only front end is changed.

Is this approach correct to deploy the front end even if nothing is changed on it (same for backend)?

Or should I have two pipeline and releases for front end and backend?

PS: I am the only developer in my team.

Pawan Nogariya
  • 213

4 Answers4

3

Both approaches - individual deployments and combined deployments - have they pros and cons.

Some things to consider:

  • Are you deploying to some test or staging environment, or are you directly deploying to production? Lets hope you have a test environment: whatever you have deployed to your test environment (individually or combined), make sure it reaches production in exactly that combination.

  • Did you notice any problems with your current approach? Is it too slow, and you think individual deploys will be faster? Did you encounter any kind of errors in the past which individual deploys could have prevented? If not, why do you want to change the current process?

So if you have some real evidence that individual deployments might improve your process and solve a known pain point, then go ahead. Otherwise, don't complicate a simple process without any real need.

Doc Brown
  • 218,378
2

If someone asks for help with some weird issue that they can't track down, to me it's a stronger statement if they can say that nothing changed vs they redeployed exactly the same application.

The problem with redeploying is that it is difficult to say that it is "exactly the same" - was there a build process that can potentially pull in a new version of a third party dependency. Was there state in memory on the target machine and simply stopping and restarting the process flushed that etc.

To be clear having processes in place to redeploy exactly the same thing every time is definitely desirable - however having a deploy run unnecessarily is just one more seed for doubt about the potential cause of an obscure problem.

DavidT
  • 4,601
1

The danger of deploying them together is you get used to it and lose the ability to deploy them separately.

There are many reasons separate deployments are useful. But until you actually have one they can seem pointless. Without a real reason the only one left is: use it or lose it.

candied_orange
  • 119,268
1

Yes it is "OK".

In your case I think it's necessary. Since you build and presumably test the front and backend together you won't have any tests for "new version of front end works with old version of backend"

If you do want to move to a less coupled, "I can deploy either separately" you will also want to split the git repository into two and have two distinct pipelines with an option to specify which version of the other project should be used in any end to end tests.

This is the kind of approach I would take if the backend is more of an API, potentially used by multiple apps, rather than a "backend for frontend" dedicated to one specific app.

However; if you are the only developer in your team then I think this approach might be overkill

Ewan
  • 83,178