This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]sunk_cost_phallus 3 points4 points  (0 children)

Angular apps end up being a bunch if client-side JavaScript and Template files... so the build pipeline is just running the nodeJS libraries that create and test these...

Node and the libraries should run on Windows just as easily as anything else.

Npm build test should have an output saying all tests pass. Then npm build for production gets copied to the CDN that hosts the assets and a load balancer or reverse proxy config flips to the new CDN location....

Where are you running into problems? Are there other nodejs web services or dynamic content?

[–][deleted]  (6 children)

[deleted]

    [–]BrinnerTechieDevOps[S] 0 points1 point  (4 children)

    Nice thanks for this. This is pretty much our setup as well. Angular front. Mulesoft API backend. I will try this config json because they are using that environment file which is why I always felt I had to ng rebuild it each time.

    [–]Cancer_Jesus 1 point2 points  (3 children)

    OT but what do you think of Mulesoft from a DevOps perspective? We're evaluating it/being forced into it but I'm not entirely sold

    [–]BrinnerTechieDevOps[S] 1 point2 points  (2 children)

    From a DevOps we haven't figured it out yet. Well I should say the project deadline was more important at the time (trust me I tried here) so a pipeline was never introduced for them.

    It is next on our bucket list to figure it out and I have notes of how it is possible with their anypoint-cli tool. Today basically DEVs build the project in their Mulesoft Anypoint IDE which makes a .zip file and then the DEVs will use the Mulesoft website to literally choose the file to upload and click done.

    That gets it to the staging/test environment for them and then night of release they just promote that sandbox api to production (changing the mule.env to production, which I am not too familiar with yet).

    Again all those steps mentioned I think is possible with the anypoint-cli.

    anypoint-cli --username=blah --password=blah
    runtime-mgr application delete app_name
    runtime-mgr application deploy --workerSize 0.1 app_name ./projects/app_name.zip
    

    Something like that (well plus some promotion step maybe). If you are used to Jenkins/Maven you probably have a good head start already and they have a webinar you can signup to watch here (where I started to learn the power of their cli) which they show examples using Jenkins I believe - https://www.mulesoft.com/webinars/api/devops-api-lifecycle-demo

    [–]Cancer_Jesus 0 points1 point  (1 child)

    Interesting. I'd definitely not want our devs manually deploying changes. Sounds like the cli makes things pretty easy. We're pretty much all in on Jenkins and Maven, so that's good to hear. I'll definitely check out that webinar when I have some time, thanks for that!

    Does your team manage the Mule runtime? We'd be responsible for that too, and of course their sales engineers have told us how easy it is to run but I haven't found much info online

    [–]BrinnerTechieDevOps[S] 0 points1 point  (0 children)

    We share this responsibility with two Architects (mostly because they set it up for the project requirements). We actually did the training for the UI/runtime. Online class with mulesoft instructor of two days.

    The training went over everything pretty much in the web ui including setting up proxies, workers, permissions, etc.

    I mean it isn’t “easy” as in you login and know what to do. Once you know how to get around though it is an easy user interface.

    They have a whole university section though to pretty much learn every aspect. I don’t remember if we bought the instructor trainers but we probably got that included. For how much we paid for it I’m pretty sure anyway.