Normally my code is stored on Bitbucket and built using some CI service like codeship. During build process new file is created for example "myapp-v1.2.3.zip" or "myapp-v0.0.1.exe" etc. From this point packages are deployed to FTP or directly to server or to S3 - generally to a place from which user can download them.
My question is if there exists service to store such code releases (specially dedicated for this purpose) - for example with public dashboard with all versions of myapp listed and available to download etc? And maybe simple API to check latest version, dev versions, stable version etc.
Bintray is the software distribution service provided by JFrog, the makers of Artifactory.
https://bintray.com/
Related
I am trying to set up a rest API that is connected to an IBM blockchain resource. I have developed a model file, logic file, and acl file.
I have it all packed up in a nice tidy .BNA, and now i would like to deploy it to a channel of my IBM cloud blockchain 2.0 resource, running on a free kubernetes cluster.
Everything on the cloud blockchain resource is set up perfectly, and all orgs, peers, orderers, msps, and CAs are set up correctly. The channel is set up properly, and has nodes and an MSP connected. I have all the admin cred .jsons
The channel only accepts smart contract files, so I tried repackaging the files (logic.js, permissions.acl, and model.cto) by putting them in a contract folder, and using the IBM Blockchain vsCode plugin to package them as a smart contract, but trying to install on the IBM cloud crashes the browser.
I am thinking maybe I have to remote connect into the IBM kubernetes cluster that the blockchain resource is sitting on, and use the hyperledger composer CLI to install the .BNA
Seems very unintuitive, but thats the one thing I can think to try while I wait for this question to get answered.
I expected to just be able to install the .BNA as a smart contract, like a .cds.
In August 2018, IBM announced that we are no longer investing in Hyperledger Composer, and instead focusing 100% on Hyperledger Fabric. As a result, IBM Blockchain Platform v2.0 will not provide any support or tooling around Hyperledger Composer.
The good news is that we've significantly invested in the programming model (APIs and SDKs) used to write smart contracts and applications in Fabric v1.4, and we've also released some great developer tooling in the form of an extension for Visual Studio Code: https://marketplace.visualstudio.com/items?itemName=IBMBlockchain.ibm-blockchain-platform
The extension offers an extensive set of capabilities for writing smart contracts - with tooling for creating new projects, packaging them, deploying them, testing them, and debugging them - all from within one of the most popular IDEs around.
To get started - just install Visual Studio Code, and then the IBM Blockchain Platform extension (there are a few prereqs, check the README first). After that, you will be presented with a homepage that links you to tutorials and samples to help you get started.
For the first one, I can't really suggest a solution. At best, try installing and using the composer CLI and the latest version to make the bna file. Composer playground isn't maintained as well imo.
For the second part, in the connection.json file and docker there will be a bunch of IP addresses that look something like localhost:7040 and so on for the CA, orderer, org and peer. You will need to replace these using the IPs given by IBM. The examples on github that demonstrate integration are to do with nodejs SDK and not composer, however you can refer to https://github.com/IBM-Blockchain/vehicle-manufacture to get the idea.
This link is the only I could find for Hyperledger Composer and IBM platform.
(comments were getting too long to fit)
Google Compute Platform
I've got an Angular (2) app and a Node.js middleware (Loopback) running as Services in an App Engine in a project.
For the database, we have a Compute Engine running PostgreSQL in that same project.
What we want
The testing has gone well, and we now want to have a test version (for ongoing upgrade testing/demo/etc) and a release deployment that is more stable for our initial internal clients.
We are going to use a different database in psql for the release version, but could use the same server for our test and deployed apps.
Should we....?
create another GCP project and another gcloud setup on my local box to deploy to that new project for our release deployment,
or is it better to deploy multiple versions of the services to the single project with different prefixes - and how do I do that?
Cost is a big concern for our little nonprofit. :)
My recommendation is the following:
Create two projects, one for each database instance. You can mess around all you want in the test project, and don't have to worry about messing up your prod deployment. You would need to store your database credentials securely somewhere. A possible solution is to use Google Cloud Project Metadata, so your code can stay the same between projects.
When you are ready to deploy to production, I would recommend deploying a new version of your App Engine app in the production project, but not promoting it to the default.
gcloud app deploy --no-promote
This means customers will still go to the old version, but the new version will be deployed so you can make sure everything is working. After that, you can slowly (or quickly) move traffic over to the new version.
At about 8:45 into this video, traffic splitting is demoed:
https://vimeo.com/180426390
Also, I would recommend aggressively shutting down unused App Engine Flexible deployments to save costs. You can read more here.
I have an application that was pushed to the Liberty runtime via the packaged server deployment method. In the future, if I make changes to my code without having to change my server.xml, do I still have to build a package and deploy the same way? Or can I just Commit and Push my changes from Eclipse or DevOps straight into Bluemix?
you still have to push your application using the packaged server deployment method, because even if the push action uploads only what needs to be updated, it makes a full restaging once the upload is completed.
By this way, if you push only your application files without using the packaged server deployment method, it will use its server.xml template overwriting all your previous customizations.
If you are using IBM Eclipse Tools for Bluemix you can take advantage of incremental publishing support by putting your packaged server in development mode. Right click on your packaged server and select Enable Development Mode. Once enabled, you can make changes to applications that are deployed on the packaged server and then once you are finished with the changes, right click on the Bluemix server and select Publish. No re-push is required and only changed files will be copied over to the Bluemix server saving a lot of time. See the following for more details: http://www-01.ibm.com/support/knowledgecenter/SS8PJ7_9.5.0/com.ibm.etools.iwd.doc/topics/tincrementalpublish.html. As you mentioned, if you change the server configuration (server.xml) then you will need to re-push the packaged server. Incremental publishing is supported for applications deployed directly to Liberty on Bluemix as well.
Over the last few months I've become familiar with the AWS OpsWorks deployment process as it pertain to Node.js - deployment for Go seems to be another animal.
From what I've gathered, this is what I need to compile a successful Go deployment:
Install go on the EC2 box
Pull the private repository from GitHub
Pull in all dependencies
Compile the main package for the box's arch
Start the binary with a couple of flags that I use
Everywhere I have read seems to tout the ease of Go deployments because dependencies are included in the binary, but that seems to imply that you are compiling the application in your development environment and pushing that up to the cloud. This doesn't seem like a process that works well across a development team.
https://github.com/crowdmob/chef-golang-web-server-cookbook
I have been attempting to get the Chef Scripts from CrowdMob working, but to no avail. I continue to get errors that look like this:
[2014-08-01T16:08:22+00:00] WARN: Cookbook 'templates' is empty or entirely chefignored at /opt/aws/opsworks/current/merged-cookbooks/templates
What is the proper way to deal with dependencies during deployment?
Are there any established practices for deploying Go onto AWS with Chef?
Use a continuous integration service like CircleCi, Travis or your own setup Jenkins.
On the Continuous integration service then
Add a github post commit hook .
Test / Build the binary
Create the zip file as artifact
At this point you can create an new version on Elastic Beanstalk using the AWS commandline and the zip file created from this version.
venv/bin/aws elasticbeanstalk create-application-version ...
Then just select which version to deploy from the EB dashboard.
For simple services using Chef is overkill IMHO. Docker offers a simple workflow.
Use the Docker container option and then use elastic beanstalk's command-line client to initialize your environment in the project root directory and then you can simply do a 'git aws.push' from the same place.
With the correctly configured Dockerfile in your project and pushed to eb, the EBS' docker container app will pull the correct image with golang installed, then do a go get on your projects dependencies, and then compile and run your app. It sounds way more complicated but it's actually very easy.
Below is a link to a video walkthrough I did for running a simple golang webapp on EBS. The method for uploading the project does not use git. Instead, I zip it up and upload it, but the git method is recommended (and I do it) for automating deployment.
YouTube: How to run a go web app on Amazon's Elastic Beanstalk
I also had some problems to setup a good building process with Elastic Beanstalk and Go.. I don't want to use Docker, and all the people seems to be going on this direction.. so.. you can take a look at this project: https://github.com/battle-arena/heimdall
There you will find a custom setup using the Buildfile and the Procfile.. and I rely on a CI system to build the release package...
Basically I do the following:
Hook the commits to a CI system
On the CI system I run the test and the install.sh if all good
The install.sh will create a build folder and a structure that will be sended to the Elastic Beanstalk with the aws-cli tool
After send to the EB the Buildfile will run the build.sh that will basically extract the compressed package with the proper structure, and run a go get ./... and go build
The Procfile will run the generated binary
I think the result is pretty good, and you can use with any CI tool.
We are currently using web deploy for creating packages for our .net web applications. It got some pros and cons. Now we are going to use nuget for dependency management but given the ease of packaging in nuget .. i am debating on should i still use web deploy + remote service or try to use nuget to bundle my web application and use powershell or something like octupus to deploy ??
For my web deploy becomes little complex when even try to do simple things like include , exlcude , gac or registry or iis config ( which again not very flexible ).
But on the other hand it comes with remote service and all i need to do is through the package to the service and i am done..
Please give your inputs on this comparison.
-raj
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time. From a deployment perspective, it doesn't offer you any more than what a zip file does... except all the overhead of trying to fit NuGet in the process.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I am setting up a system that uses NuGet and Webdeploy.
NuGet is used as the repository format, so the build system publishes NuGet packaged artifacts.
The Deployment systemn uses NuGet to get the RIGHT packaged artifact from the NuGet repository.
The build artififact happens to be WebDeploy for easy installation.
I am still working out if I am going to use puppet, chef or octupus to orchastrate the deployment.