Deployment on production server

[next maple]

I'm trying to deploy a project to a server, and while looking at examples, I came across this:

{
"name": "new-projet",
"version": "0.0.1",

"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"watch": "ng build --watch --configuration development --base-href /projet/",
"test": "ng test",
"deploy": "ng build --configuration production --base-href "/angular_intranet/" --output-path "\\[server]\Users\[utilisateur]\Documents\new-projet\dist""

},

and I wanted to know if the ⁨dist⁩ directory is important on the production server?

[gaunt plank]

the dist dir is the ONLY one that should land on the production server

hence it's name. dist(ribution)

[next maple]

Okay, so if it's a production server then it's on dist, but for local servers there's no need.

[gaunt plank]

what do you mean by "local servers"?

running ng serve?

[next maple]

For local development and testing, I use the "watch" command: "ng build --watch --configuration development" and for deployment to the server, I use this one: "deploy": "ng build --configuration production"

And locally I'm also monitoring my Angular project "watch": "ng build --watch --configuration development" and put it on IIS

[next maple]

And what is this error that occurs when I try to deploy to my production server?

[gaunt plank]

are you building the project ON the prod server?

and what's the reason you're running it through IIS locally?

[gaunt plank]

and i would assume as the message suggests you don't have the required perms the way you're accessing the server (as a mapped network share?)

[next maple]

Configured by a previous person who managed the project

[next maple]

When I launch the deployment (the compiled version), I am in a local session (on everyone's PC).

[gaunt plank]

"I am in a local session (on everyone's PC)." what does this mean exactly?

[next maple]

This same person had made an earlier version of the project separately, and it's also like this, but this earlier version works.

[gaunt plank]

based of the code you showed, using the ⁨⁨\\⁩⁩, it looks like you're accessing a remote server via the windows network share system

[next maple]

I admit I can't quite describe it, but the local session is my computer session and the server is when I connect to it from a remote session, is that clearer?

[gaunt plank]

not really, but maybe i'm just being dense.

there are two machines in that scenario, yes?

your local pc and a remote server?

in any case it's a permission issue. so you gotta figure that out with your hosting department? or whoever is responsible for the AD stuff^^

and on a side note, deploying manually instead of a CI pipeline is very much suspicious

could maybe try to do the build locally first (removing the output path to the server) and then simply copying the dist folder to the server (with a script! not by hand)

maybe only copying works around the permission issue

[next maple]

Yes, I do have my local PC and remote server, and I also have access to Active Directory.

And why is it suspicious to do it manually?

Personally, I'm still new to development, and I have to learn how to deploy the Angular 19 project, and later its API, to IIS on a remote server. For the deployment, I based it on what my previous colleague did, and I admit I'm having trouble understanding how it works, or if it's even a good way to do it.

[next maple]

Shouldn't you do it like this instead?

"deploy": "ng build --configuration production --base-href "/angular_intranet/" && robocopy dist\intranet "\\VM-28-ADAM\Users\Administrator.ADAM\Documents\intranet-web" /E /PURGE"

[gaunt plank]

Well first of all, you shouldn't even have access to the prod server directly on a networking level
(if your pc is compromised for example, they could access your prod stuff too)

Builds should run in a C(ontinuous)I(ntegration) pipeline
you commit your changes to git (or whatever source control you're using) which then triggers (reproducable) builds that are deployed to the prod server (and best case, can be rolled back easily)

[gaunt plank]

since all of the above is not something you can easily build if you haven't done it before then yes, this might fix your current issue

but i still heavily recommend looking into the aforementioned topic of CI builds and deployments

there's many more reasons for limited access to prod and CI stuff if you look it up online too
in case you need arguments to convince your higher ups to invest time into it

on a slightly more (angular) unrelated note, considering you're using IIS i assume your api is written in C#

It's 2026. .NET on linux is a thing for a while now. It's time to ditch windows servers (and their ridiculous licensing fees) and switch to a linux server 😛
Makes they deployments easier too (compared to IIS)

[next maple]

Hmm, I see. I'll add some more information.

First, the project is on Git/GitHub, which, as you said, makes it easier to revert to previous versions, and with GitHub Desktop, it's fantastic.

Regarding the connection, even on the PC I have, I need to be on the internal Wi-Fi to access the remote service and other things, and it always requires a password. PS: I also think it's not very secure, but I don't have a choice; I have to deal with it.

Furthermore, my boss and I are only in phase 1 of the server access setup for managing Active Directory and other things, but if there's a bigger problem, our service provider takes over.

And regarding the Linux or Windows server, well, I don't really have a choice but to use it. It was decided this way, and I can't do anything about it for the moment, so I have to manage with it.

Finally, I'm going to try this and see "deploy": "ng build --configuration production --base-href "/angular_intranet/" && robocopy dist\intranet "\VM-28-ADAM\Users\Administrator.ADAM\Documents\intranet-web" /E /PURGE"

[gaunt plank]

First, the project is on Git/GitHub, which, as you said, makes it easier to revert to previous versions, and with GitHub Desktop, it's fantastic.
what i meant with reverting wasn't your local code repo, but deployments to the prod server.
When you have a CI pipeline you could say "store the last 4 successful builds" and when you accidentally deploy a broken version, you can just deploy a previous build. without having to rebuild or checkout an old state

Regarding the connection, even on the PC I have, I need to be on the internal Wi-Fi to access the remote service and other things, and it always requires a password. PS: I also think it's not very secure, but I don't have a choice; I have to deal with it.

Furthermore, my boss and I are only in phase 1 of the server access setup for managing Active Directory and other things, but if there's a bigger problem, our service provider takes over.
for the record, i'm not assuming you will or even can "fix" this overnight. i was just answering your question why it's not really up to standards^^

And regarding the Linux or Windows server, well, I don't really have a choice but to use it. It was decided this way, and I can't do anything about it for the moment, so I have to manage with it.
sad times

[next maple]

Oh, sorry, I didn't quite understand everything in the same way.

However, the idea of ​​keeping the last four successful deployment versions on the server really appeals to me. I'll just need to look into it further because it's a really useful feature. If you have any documentation to guide me, I'd be very grateful.

But for now, I'll do as I described earlier with the "deploy" command.

[gaunt plank]

just read up on continuous integration/delivery/deployment pipelines
for github it's called github actions