I'm kicking the tires on the preview for the Visual Studio Team Services new Release Management system. My scenario is a classic website (ASP.NET 4.5) with a Git repo hosted in VSTS. The build definition is successful as seen here:
It is set up to publish as an artifact that can be picked up by Release Manager as shown here:
On the Release Manager side I have that artifact linked properly as shown here:
And here you can see my environments as well as the associated tasks (all 3 are clones)
When I run the release the build publishes fine, it connects to my subscription but when it attempts to find the package file it has the following error on line 101 of the output log:
"No files were found to deploy with the search pattern 'C:\a\4fe43dd1a***.zip'"
Here is the full output:
This is where I am stuck as I assumed my artifact link via VSTS should resolve this path for me. Obviously I am missing an important piece of the puzzle somewhere, but I've followed the available documentation as best as I can.
If anyone has a solution or can point me in the right direction it would be much appreciated!
--- EDIT ---
I used the file picker to select a web deploy package (see below). I tried using the root website as well as the bin folder. Both attempts results in an error stating: "No files were found to deploy with search pattern 'C:\a\4fe43dd1a\Classic Website Definition\drop\ClassicWebsite\bin'"
--- EDIT 2 ---
I added an MSBuild task to my BUILD process with the following MSBuildArguments
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
and in my Copy/Publish Artifacts task I limited my output to only copy .zip files. Now in my RELEASE process when I navigate to find a "Web Deploy Package" the "drop" folder is empty. Here is a screenshot:
I think I'm on the right path, I just need help figuring out to tune my BUILD tasks to generate the right artifacts for my RELEASE process to use. Any help would be appreciated.
The deploy package isn't copied to artifacts folder. That's why the release management cannot find the package. Setting "Copy and Publish Build Artifacts" to the following should fix your problem:
Change $(System.DefaultWorkingDirectory) to $(Agent.ReleaseDirectory). The artifacts will be put in that folder. I don't know exactly what $(System.DefaultWorkingDirectory) maps to, but my impression is that it's something outside of the folder used by the agent for your release.
Also make sure that the published artifacts contains the expected zip file -- if the deployment package isn't getting created, or if you're not publishing the output folder that contains the package, obviously you won't be able to release it later.
When you build your web application, make sure it's packaging for deployment by using MSBuild arguments that package it up. Something like this should work:
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
Related
I have two webapps - "manager" and "viewer" - coded in separate VSCode projects. These are deployed to a common Firebase project where they share a common database. The "manager" webapp is used to maintain the database and the "viewer" provides public read-only access.
To create the "page" structure I have added a robocopy to React's build script for each VSCode project to produce a structured "mybuild" folder with the page subfolder within it. Firebase.json's "public": setting is then used to deploy from "mybuild".
Individually the two pages work fine, but each deployment overrides the functionality of the other. So, following the deployment of "manager", webapp/viewer returns a 404 (not found) error and vice versa.
To cut a long story short, the only way I've found around this is to manually copy the results of a deployment for one project into the "mybuild" folder of the other and then deploy from this. But this is no way to proceed.
I think I've taken a wrong turn somewhere here. Can anyone suggest the correct "firebase solution" for this requirement? In the longer term I'd like the viewer webapp to be available at the root of some user-friendly "appurl" while the manager is accessed via "appurl/manager", but other arrangements would be acceptable. The main issue right now is finding a simple way of maintaining the arrangement.
I needed to fix this fast, so here's my own answer to my question.
It seems that when you deploy a project, firebase replaces the current public folder for your URL with the content of whatever folder is specified in your firebase.json. So I decided that I had to accept that whenever either of my projects was deployed it must deploy from a "composite" folder that contains the build files for the other project as well as its own build.
That being the case, it seemed I was on the right lines with my "manual copy" approach and that what I now needed to do was simply to automate the arrangement.
Each of my projects now contains a script file with the following pattern:
npm run build
ROBOCOPY build ./composite/x /E
ROBOCOPY ../y/build ./composite/y /E
firebase deploy --only hosting
In each script, x is the owner project and y is the other. Additionally, firebase.json in each project is edited to deploy from composite.
When I run the script for a project it first builds a composite folder combining the latest build state for both that project and its partner, and then deploys the pair.
The final twist is to tell the react build process that the result is to be deployed from a relative folder and so that the build therefore also needs to use relative references. I do this by adding a
"homepage": "https://mywebapp/x",
to the package.json for each project. Here, x is the name of the project.
I'm not able to convince myself that there's not something wrong with my whole approach to this issue, but at least I have a fix for the immediate problem.
I am trying to package Service fabric application, when i do that i have application manifest and service manifest files but i want to include application parameters and Publish profiles as well.
Not sure what CI system you're using but typically there's three parts to make it all work
Package your application output + manifests. This is basically the package location output you get from doing an MSBuild on your sfproj. In below, I'm assuming CI build artifact output go to '$(build.artifactstagingdirectory)'
/t:Package /p:PackageLocation=$(build.artifactstagingdirectory)\applicationpackage
Include a step in your CI build output to copy the the parameter and profile files to another folder - e.g. $(build.artifactstagingdirectory)\projectartifacts
**\PublishProfiles\*.xml
**\ApplicationParameters\*.xml
Deploy your application. For this, have a look at the Deploy-FabricApplication.ps1 script that's created by Visual Studio when your first created your .sfproj Service Fabric project. This is also used by Visual Studio when you deploy your application to your local development cluster and you essentially have to perform the same steps to deploy to another cluster.
A simple example assuming your CI artifact output exists in "$(SF_PackagePath)"
Deploy-FabricApplication.ps1 -ApplicationPackagePath "$(SF_PackagePath)\applicationpackage" -PublishProfileFile "$(SF_PackagePath)\projectartifacts\Local.1Node.xml"
I'm using ReactJS and need some help with the build.
I am hosting a static site on a dedicated server.. in order to process that site I currently run my build locally and upload the 'build' folder to the server.
I've recently decided I should probably generate some static files for SEO (and adsense approval) and therefore I've added react-snap.
I run npm run build from my directory, and react-snap runs postbuild as expected however it fails unless I upload the build to the server first and then run the same build again to generate the static files (and then have to upload these again to the server for the static content to be available for search engine crawling).
I'm obviously missing a fundamental step in my build process here. I already want to refine it to a Git and push that to the server but I don't think this will help my react-snap problem.
Can anyone help?
Answering my own question for anyone with this problem...
My production variable for homepage was set specifically to the domain.. this is not required and does not allow for local crawling of the site. Explanation here:
https://github.com/stereobooster/react-snap/issues/153
We are developing a project built with yeoman angular generator. Now appears the need of "puppetize" it for deployment.
Obviusly the machine serving client part should be provided with a compiled (minimified, optimized) version of the angular project. But I have no idea if we should store it on our bitbucket repo -for example on the master branch when tagging a new release-
I couldn't find any post about this practice and I could use some help.
There are some facts about angular minified version:
It is uglificated and minificated, so code is unreadable and hard to change.
It demands compilation with tool like gruntjs, which takes some time to build each time.
It works on server, but when you choose to deploy non minificated, revisioned version, you can have other problems during adding new versions to same repo - scripts have same name and are cached in browser and possible other problems.
You decided to deploy compiled version to a client machine.
If you are using version control like git. you can add to repo a folder with compiled version, so your repository have sources and dist in same folder. Possibly you have also backend code, sometimes in backend code you can add compiled version to host on server. It's better to have all code and builds in one repo, so you can do this with one command.
In my case, i wrote scripts in java, to copy builded folder to another folder. We use also Visual Studio for backend, so i wrote script adding new filenames to .cs file, so it can be visible by continous integration tool.
Going to a final, create new branch in git from release master branch. It is useful to have copy of your partial work.
I don't know how often you have releases, but you can solve it by having branches in git.
So your branches can look like this:
master
release1
release2
...
Assuming you are doing development on master and copying new versions to releases.
I recently relocated my Eclipse Java GAE project to a different location on my computer. (And both locations are under Dropbox. ) Since then, I've been having issues with deployment. When I make changes to files and save them, sometimes it doesn't recognize the changes and doesn't upload them (so when I deploy through Eclipse, it says uploading 0 files and the live deployment is not updated).
Sometimes it does work (after several clean's and restarts to Eclipse).
Any help on how to fix this would be greatly appreciated, thanks!
It seems solved now, some notes to consider
Ensure that you are not manually modifying (adding/removing) libraries under war/WEB-INF/lib folder. Add to that folder only when you are using the libraries. (I had some unused libraries there)
Ensure that war/bin/classes are cleaned after you clean the project
I reinstalled the plugin as well, just in case