I used to group related parts of my application like so:
Project Name
--Web UI
--Windows Service
--File Drop
"File Drop" is an example that might be related to both the service and the web site.
However, tentacle deploys each package separately, so with that I get something that looks more like (assuming ProjectName is used in the package id):
--ProjectName.WebUI
--ProjectName.WindowsService
How should I deploy a related shared folder? Can you group applications in some way? If not is there a recommended pattern to creating shared resources?
I should add that I'm using octopack. I figure I certainly can manually put a nuget package together and use the relative dir parameters for IIS Sites and Services, but that starts to get more difficult.
It sounds like you want to use Custom Installation Directory. This will let you control what directory the package is extracted to.
You can also do some custom setup in a deploy.ps1 file for each of your packages.
Related
I am trying to create my first monorepo in Go. The project structure looks as follows:
As you can see on the picture, the monoplay folder is the root.
The pb folder contains the generated gRPC code that I would like to consume in the srv_boo/main.go and srv_foo/main.go files.
The question is, how to consume the generated gRPC code from folder pb in the srv_boo/main.go and srv_foo/main.go files?
Is the folder structure correct?
Would like also to deploy the services individually.
Is maybe https://bazel.build/ the solution?
Having the entire repository as one go module will help with this, i.e only one go.mod file in the "Monoplay" root folder.
Then the services can reference the generated go files using "github.com/*/monoplay/pb/*" imports.
This will also centralize dependency management for all the entire repository, since there is only one go.mod file, if that is something you want.
Other alternatives:
Using "go mod edit":
https://go.dev/ref/mod#go-mod-edit
Or, as DazWilkin suggests, use "go_package" in proto files together with "go-grpc_opt" and "go_opt".
I use the single module approach and recommend it.
If the repository will contain a lot of code and building everything (including container images) is cumbersome and takes to long then look into bazel.
Fabric chaincode requires separate folders for each chaincode for deployment.
for e.g., chaincode_1 will need to be in chaincode_1 folder with all the dependencies (vendor), util/library functions + chaincode_1.go and same for chaincode_2.
My question is how to organize util/library folder if it has functions that i want to use it across chaincodes. Fabric chaincode deployment does not allow it.. i think. And the util folder is replicated/redundant in each chaincode folder
You could put all of your shared dependencies, including your own util package, in a separate repository and then vendor them via dep. They would still be replicated per chaincode, but it might be easier to manage them via dep ensure rather than having to manually copy them.
In AWS Elastic Beanstalk, there is a wizard flow for deploying node.js apps. When I get to the step for "upload your own" application source, it describes in generic terms their 3 requirements: zip file, less that 500MG, no parent folder.
But they stop there. No specifics.
I dropped out to bash and ran...
ng build --prod
...and now have a dist folder. So... what do I include in my zip file and at what folder level? I have tried just /dist, and also /myapp/dist which included all the other loose files in /myapp but no other sub folders such as /src. I have looked all over the web, but don't see what should be a fairly simple tutorial on zipping up an Application Source Bundle for AWS EC2.
What should be included in the zip file for upload?
The cardinal sin in my question above was attempting to run my Angular 5 app in AWS by using their choice for node.js as my server platform. Here is what I learned (with some help from folks like Albert Haff: Angular 5 uses Node (ng serve) to simulate a webserver while you code. However, even though there is a supported flag for --prod, it's not to be used in production! It's really easy (and tempting) to select node.js as the environment when deploying your Angular 5 app via Beanstalk -- but don't do it!
from within your Angular 5 project folder, run ng build --prod ( and consider adding --aot)
if you can, from within the new /dist folder that the build just created (or updated), optionally run compression like for i in dist/*; do brotli $i; done
from within the /dist folder, zip up ALL the contents including subfolders.
go to beanstalk, and as you create a webserver environment, select Tomcat (or any other plain old webserver, but DON'T pick node.js even though it's on the list!).
on Application Code, select to Upload Your Own, and browse to the .zip file you created in step 3 above.
click Create Environment and in a few minutes your Angular 5 app will be serving up on the internet.
Now, from here you will likely need to connect up your domain name. Use Route 53 for that.
Revel models are defined under the models package; so in order to import them one must use the full repo path relative to the %GOPATH/src folder which in this case project/app/models thus results in
import PROJECTNAME/app/models
so far, so good i'f you'r using your app name as the folder name of your local dev machine and have dev+prod environments only.
Heroku's docs recommends using multiple apps for different environment (i.e. for staging). with the same repository with distinct origins;
This is where problem starts, now, since the staging enviromnent resides on alternative appname(let's say PROJECTNAME_STAGING), it's sources are stored under PROJECTNAME_STAGING but the actual code still import PROJECTNAME/app/models instead of import PROJECTNAME_STAGING/app/models; so compile fails, etc.
Is there any possibility to manage multiple environments with a single local repo and multiple origins with revel's heroku buildpack? or a feature is needed in the buildpack that is yet to be implemented?
In addition, there is this possible issue with the .godir file that is required to be versioned and contain the git path to the app, so what about the multi-environment duality regarding this file?
Solution was simple enougth;
The buildpack uses the string in .godir both for the argument for revel run as well as the directory name under GOPATH/src. My .godir file had a git.heroku.com/<APPNAME>.git format; Instead I just used APPNAME format.
I have a solution that contains multiple integration test projects and one web application project. each integration project connects to the web application when running the tests. I would like for each test project to access the website with its own database connection. I have been trying to use the web deploy functionality built into visual studio. However I have been unable to figure out what I need to add to either the deployment package that is created and/or the post build event for the test projects to declare the binding port for the website when deployed. For example, I want integration project A to create and access the website located at http://localhost:83 and integration project B to create and access the website located at http://localhost:82. Could someone please explain:
Is there anything I need to do the deployment package ?
What do I need to add to my post-build events for my integration projects when deploying the package, so that the website is created at the correct port when building the project?
Update:
I'm wanting to deploy the same site to two different locations on my machine so that I can run both sets of integration tests at the same time.
Update 2:
I have researched the web deploy tool and it allows you to specify parameters that modify what is deployed when you call it from the command line. However I have found the documentation very confusing. http://technet.microsoft.com/en-us/library/dd568968(WS.10).aspx
Update 3:
I expect these to be two different websites, each pointing to there own database. If possible I would like a single package that can be deployed using msdeploy. Which will then be called in a post build event from each of the integration test projects. I would like to specify the connection string and deployment location from the post build script of the integration project.
you can try with webdev.server included in visual studio. VisualStudio use this for start a webserver when you debug. With this you can start a webserver in the desire port (if the port is not used currently).
I made a bat file for change some options.
check it.
::Begin of bat file
cd C:\Program Files\Common Files\microsoft shared\DevServer\10.0\
WebDev.WebServer40.exe /port:80 /path:"C:\PATHTOYOURWEBPROJECT" /vpath:"/NAMEOFYOURWEBPROJECT"
::End of bat file
You can acces in: http://localhost:80
I use the webserver40, but if you don't have net.4 or vs2010 you can try to find webserver[ xx version].exe
I hope that this will be helpful, and sorry for my broken english.
First off, you're approaching this the wrong way.
> I would like for each test project to access the website with its
own database connection.
Who is creating the DB connection? Your web site or the test project? For rest of your question to make sense, I presume its the web site (otherwise, Project A and Project B cannot share a connection out of the box).
If your website is making the connection, unless you're caching or having a static connection, there will be a new connection made as each request runs your your site on a new thread. Another simpler alternative is to take a query param and initiate a new connection based on that. If you seed it off the caller, you can also use it for more detailed logging.
Web Deployment projects are meant for deploying to integration servers, so that means you cannot access them by http://localhost... but the full FQDN of the server.
Most importantly, http://localhost:82/myApp and http://localhost:83/myApp are two different sites (unless you redirect from one of them to another one which in itself can cause additional issues) running the same codebase.
Having said that, you would then need to deploy your website twice and then all you need is to change the config/settings entry in Project A and B to point to these to different sites.
Hope this makes sense.
You can define virtual host configuration.
Refer this guide for more information.
http://docs.jboss.org/jbossas/guides/webguide/r2/en/html/ch07.html