I am having self-hosted GitLab-EE. I want to enable CI / CD. I already have gitlab-runner on windows and it is activated for my project.
I also have custom server for hosting my ASP.NET Core 2.0 with Angular 5.0 application.
My final idea is when commit is made to GitLab, build and deploy (to custom server) is executed. Deploy path would be different if commit to master was made or any other branch (from merge request) conditional by Git Tag.
Almost all tutorials use docker, but I couldn't found why? What are the cons using docker?
I thought I only need msbuild (I can also install Visual Studio) on machine where GitLab-runner is running. It would build and deploy application. I found this configuration file which doesn't use docker, but question remains. Do I need docker and why?
A docker image would contain all the msbuild dependencies and build tools needed to build your application with out you going through the trouble of manually installing them on your server.
So basically docker helps you to manage dependencies of you application more efficiently.
Related
I am trying to figure out how to use deployment groups.
I have an artifact that contains an asp.net core website which uses "gRPC". grpc makes the package incompatible with IIS, but runs fine with dotnet ABC.dll. So thats what I try to do. Now when creating a release pipeline, only the IIS Stages have a description for the "Deployment group". All the others don't.
Basically I want to download my artifact to the servers in the deployment group, unpack the zip and execute dotnet run inside the folder.
Are there any other release stages compatible with deployment groups? Or should I try to use docker to run the artifact on the on-premise servers?
Update: The answer from Shayki works, i marked his post as answer. Anway, for anyone else as blind as me: after creating a task, you have the default "agent job". Delete that, and add a "deployment group job" with the 3 dots on the "deployment process" card instead:
You can add any task to a deployment group job, not only the IIS Stages. just add in the release a new Deployment group job and add there your tasks (unzip and dotnet run):
Because it's a Deployment group job the job will download the artifacts to each server that exist in the group and will invoke the tasks.
I'm looking into using Nuxt.js for a new Web application with an Express server / API attached in the project itself. I've created the Nuxt.js application with the npx create-nuxt-app command and selected Express as "custom server framework".
When using the development environment (npm run dev), it works like a charm. Now, I want to deploy the application to a server which is running pm2 using Gitlab CI. I struggle with the right way to deploy the application, as I don't think I should "upload" the sourcecode to the server and then run the neccessary commands like npm run build or npm start. So, what is actually "the right way" to deploy this application with the server?
I have SSH access to a server where I want to deploy this application & API. The server is running pm2 for managing the Node processes.
Furthermore, the sourcecode is in a repository on a Gitlab server with a Gitlab CI Runner available. The current gitlab-ci.yml does the following:
npm install
npm run build
lftp the dist folder to the server
With a SPA, only the client is built and the server / API is not. We now have a, in my opinion, dirty workaround which doesn't work very well that does the following:
npm install
npm run build
mirror the whole project to the server
use a watcher in pm2 to detect changes in files
build project again???
It looks like it doesn't work as intended and I have the feeling we are creating problems instead of solving the deployment issue the right way. We don't use Heroku, Google or any other services for hosting the application, it's just a webhosting with SSH access basically.
My question is about separate package/deploy steps. What I want to do is to package the service at step 1 of the deployment process, then copy the content of the package to another machine and deploy from there. Can't make it work. I use no parameters, and "serverless package" seems to work fine (creates ".serverless" folder without an attempt to deploy), but when I copy the ".serverless" folder to another location and execute 'serverless deploy" it only says "packaging service" and does nothing. Is this how deployment of a package supposed to work? This happens on a vanilla aws node service.
The command serverless deploy --package path-to-package seems to be what you are looking for, as specified in the Serverless Framework documentation.
This deployment option takes a deployment directory that has already been created with serverless package and deploys it to the cloud provider. This allows you to easier integrate CI / CD workflows with the Serverless Framework.
You were probably missing the --package option.
I've spent countless hours trying to understand how to do this correctly.
I have a nodejs application with angular front-end which are both contained in the same project.
I would simply like to have Gitlab CE CI build the project and then copy the resulting dist folder and package.json file to the production server and restart
I have a shared gitlab runner setup and was able to successfully configure the ssh runner.
Using the Gitlab runner ssh I was able to copy the entire project to the production server but cannot get it to build (plus I really don't want to have all files on the server, just the production required files.
what am I missing. do you use a docker runner with a node image to build the project and they scp files to the production server?
Any guidance would greatly be appreciated.
Yes, I think you already state the solution.
I would recommend looking into Job Artifacts to build your application in a Docker-based build job and upload the production files as an artifact.
The next job could then deploy (by scp or ssh+wget/curl) the artifact files to your production server and restart the webserver.
I just figured out, how to release to CB hosted maven "release" repository. I am trying to figure out, how to deploy tagged version to CB application.
I understand, I can manually upload WAR file but is there any script. As far as I know maven plugin for CB doesn't support it.
I have one appserver is running snapshot builds from jenkins.
I have other appserver, which I want to deploy only tagged/released artifact.
There are four ways to deploy applications to the CloudBees RUN#cloud service:
Using the bees command provided by the SDK
Using the bees-maven-plugin
Using the manual upload via the web GUI
Using the CloudBees Deployer plugin for Jenkins
Which option you choose depends on where the deployment will take place from... And the from I am talking about is which machine is doing the deployment not where the file is sourced.
If running from a Jenkins job, the best bet is the Jenkins plugin.
If running from your own laptop, the web ui or the bees command is simplest.
If running as part of a maven build, the maven plugin is simplest... (Though I should warn that the maven plugin (temporarily removing my cloudbees hat and putting on my maven PMC hat) is shite and does it all arsewise ;-) )
Your best bet is to set up a Jenkins job that uses dependency:get to pull the artifact from the repo and then add a cloudbees deployer build step to push to RUN#cloud
The good news is that bashing the maven plugin into something more maven like is on our roadmap... Hopefully that will enable actions like you can achieve with the ship-maven-plugin#mojo where you can specify a specific released version for "shipping" to production.
I suppose, that what you want to do is to deploy a release artifact to your repository.
have a look at maven-release-plugin.
Briefly, what you need to do is:
$ mvn release:prepare
$ mvn release:perform
it's not so trivial, since you need to configure appropriately your pom.xml to get it working. Have a look at the maven-release-plugin examples and usage pages.
Are you creating the tag/release from a Jenkins build? If so you could probably use the Deploy to CloudBees post-build step with target/checkout/something.war.
More generally I guess you would want to write a script to use mvn dependency:get followed by the Bees SDK to obtain the latest released artifact and deploy it.