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.

Improve this question
2
  • 3
    Decisions like this are really based on whatever works for you and your stakeholders' needs. If it works for you then keep it simple and don't fix something that isn't broken.
    – Ben Cottrell
    Commented Nov 1 at 9:03
  • "Is it okay" is a matter of context and subjectivity, making it a bad question for this site's general format. The pragmatic answer here is that the onus is on you to put forward that there is a concrete problem. People only really call things okay when there is an absence of problems.
    – Flater
    Commented Nov 1 at 23:53

4 Answers 4

Reset to default
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.

Improve this answer
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.

Improve this answer
5
  • 3
    This argument is correct, unless it is turned against itself. Having two strongly coupled components (lets call them front end and backend) compiled and tested together and then (re)deployed to production, even when only one of them actually changed (or should have changed), can sometimes be less error prone than testing them together and then deploy only one of them to production. Deploying only the frontend can be interpreted as "backend hasn't changed" (compared to prior version in production), or "backend might have changed" compared to corresponding version in the test environment).
    – Doc Brown
    Commented Nov 1 at 13:19
  • ... hence I am here with what BenCotrell wrote in a comment: the OP should keep things simple and try out what works best for them.
    – Doc Brown
    Commented Nov 1 at 13:20
  • "was there a build process that can potentially pull in a new version of a third party dependency" Even if you haven't pinned your dependencies (which you really, really should be), redeploying should be taking your build artifacts from Artifactory (etc) and working with those. No building anything involved.
    – Philip Kendall
    Commented Nov 1 at 14:40
  • Taking Doc Browns argument and turning it against itself - if an artifact hasn't changed it shouldn't have been deployed to the pre-prod environment (where testing was done) either, so what was tested would be what is deployed in production.
    – DavidT
    Commented Nov 1 at 23:25
  • I agree with Philip Kendall - in a ideal world, builds should be repeatable they should upload to artifact repositories, packaging into VM's or docker containers should be repeatable and they should also go into artifact repos and deploys should only be done from artifact repos - the world is not alway perfect, hence my argument about not deploying when not necessary.
    – DavidT
    Commented Nov 1 at 23:29
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.

Improve this answer
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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.