I have a project I'm working on with another developer using the serverless framework in aws. I need us both be able to deploy the stack without each other stepping on the others changes. I've been looking for an alias feature where I can provide some prefix or something that will make the deployment unique, but so far I've been unsuccessful. Is there such a feature in serverless to do this? If not how do teams deploy multiple version of the same code without stepping on each other?
You can use Serverless Stages. Set your stage to your name and your teammate can set the stage to his name.
Production and Dev can also be separate stages.
https://serverless-stack.com/chapters/stages-in-serverless-framework.html
I have to constantly manually download .rdl files from my git repository and then upload them manually to PowerBI. I don't have much knowledge of PowerBI but I'm only responsible for these deployments. This I feel is a time consuming process and I feel this could be done by automating the deployment process through a DevOps pipeline in Bamboo or similar. I research a bit but couldn't find anything relevant on this topic.
If anyone could help me out by suggesting potential solutions to the problem that would be awesome! Thank you!
Right now I am building a project and using vuejs for the front end. When testing locally, creating a .env.developement and .env.production work fine when in different environments and will show variables correctly. My issue now comes when building in azure devops. I am pointing to the dist folder and this is, obviously, only providing production variables which makes sense.
Is there a way to pass in dev vs prod environment variables to vuejs to build against in a azure devops/vue project?
Seems like there is something "magical" about the way vue is injecting these files into the index.html file and I cant pinpoint how vue is deciding which env variables to use.
Seems to me a question not related with Azure DevOps Pipelines but with Vue compile process.
I don't know a thing about Vue, but if it works similarly to other javascript /typescript frameworks, you should specify the environment in your build tasks.
In my Angular projects I may create a npm task specifying which environment to choose (i.e. npm run build:prod or npm run build:pre). And then, in my Azure Pipelines run the right task depending on the environment I'm going to deploy (you may even store the output in different build artifacts depending on the environment, so you'll have all those artifacts available in your deployment pipeline).
Finally (just a recommendation) I would recommend you to review which values you store in your .env.production file, just to be sure that it's safe to store that file in a repository. If you have some sensitive information, I'd recommend you to use Pipeline Variables instead. Pipeline Variables may be keep hidden, available only for the DevOps Team.
Regards.
I haven't done any cshtml front-end development for a few years.
What's the current, generally accepted way for ASP.NET Core front-end developers to work across a range of tools on Windows?
By that, I mean a way to have the front-end JS build and the .NET project(s) also build and to work rapidly in the browser and code.
My thinking is.
We have much better command line story around dotnet today.
Some folk like VS Code.
Some folk prefer VS 2019, and some like either, depending.
We need to work on UI aspects sometimes.
But we also need to attach a debugger and debug the server logic sometimes.
The build server should have no problem, be simple, and rely mostly on build logic held in the repo.
Tooling, and kicking off the whole build and serve process should be understandable and familiar.
It should be pretty simple to get going after a team noob clones the repo.
My initial thought would be to setup NPM then use something like Gulp to kick off everything, including running dotnet run.
Then when running under the Visual Studio 2019 debugger, use the Task Runner Explorer to kick off the Gulp stuff but skip the dotnet run part.
(shame there doesn't seem to be a command line for start VS(Code or 2019) and attach debugger)
Now I'm expecting to get a "primarily opinion based" SO beating, but there are general trends and ideas that go into designing all these tools for how they can all play ball together and what the dev story looks like.
You've pretty much already described the process. However, I'll add a few things:
You don't need the dotnet run bit. Visual Studio and VS Code are both capable of debugging directly.
You can assign the gulp tasks to build tasks in Task Runner Explorer, so you really don't even then to think about running those directly. I'm not as sure on this aspect of VS Code, but I'm sure there's probably some extension to handle it, if it's not already built-in.
If you want true ease of development, the best thing you can do is use Docker. Just add a Dockerfile to each project that actually runs (i.e. not a class library) and set up the steps to build and run it there. In Visual Studio, you can right-click the project and choose Add > Docker Support, and it will actually generate a ready-made Dockerfile, though you may need to add a step or two to handle the client-side build steps. In any case, this then becomes truly click and run, with nothing to worry about. The story is even better when you use docker-compose, as then Visual Studio and VS Code can spin up your entire application stack all at once, including external dependencies such as a database, Redis instance, etc. If you haven't used Docker before, start now. It's absolutely revolutionary for development.
One note for CI/CD, as much as possible, you should add a YAML file to describe your CI/CD pipeline. Depending on the the actual provider you're using for build/release, there might be some differences, so consult the relevant documentation. (Azure DevOps, for example, doesn't currently support describing release pipelines in yaml, though you can still do your build that way.) In any case, this allows you to configure all this in code, and have it committed to source control.
You may consider the same for your infrastructure. Azure has ARM templates, AWS has CloudFormation, GCP has Deployment Manager. There's also third-party tools like Terraform or Ansible. All of these, in some form or fashion (usually JSON or YAML) allow you to define all the characteristics of the infrastructure you're going to deploy to and commit that to source control. This makes deployment and things like creating new environments as breeze.
I am using Spinnaker with Jenkins. When creating a server group we have to specify the image which needs to be deployed. But my jenkins job creates an image which I want to deploy using Spinnaker. My jenkins Job number is the tag. but I am not able to find a way to mention the tag dynamically. I am able to figure out that the build number is available in parameter "context.buildInfo.number" but to use this as tag number is something which I am not able to figure out.
Thanks in advance
Amol
Just for an update I was able to resolve the problem by creating a trigger for DockerRegistry. Now one of my Pipeline Starts the Job and pushes the build to DockerRegistry. And another pipeline to monitor the images from there. It can pickup the latest build from the registry and deploy that.