Hi,

I have a process which creates a bosh release -> which has all the artifacts and use a microbosh instance to create my release. It all works great! As I move to the next step to distribute my releases to cross departments and external customers - what are the best practices around this? How do we distribute bosh releases?

Thanks,
Sumanth

If you OpenSource your bosh-release you can ask to be added to
https://github.com/cloudfoundry-community/ and you will be able to ask for
the community s3 bucket to put your final release and maybe be added to the
bosh.io website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release manifest
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

Hi,



I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



Thanks,

Sumanth

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

Typically releases are distributed to end users via release tarballs or
release git repo:

- to generate release tarball use `bosh create release --with-tarball` or
for the existing release `bosh create release
releases/some-release/some-release-7.yml --with-tarball`; users then upload
release to the Director via `bosh upload release some-release-7.tgz`
- alternatively, you can tell users to checkout git repo and run `bosh
upload release releases/some-release/some-release-7.yml`

On Fri, Jun 5, 2015 at 8:45 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

If you OpenSource your bosh-release you can ask to be added to
https://github.com/cloudfoundry-community/ and you will be able to ask
for the community s3 bucket to put your final release and maybe be added to
the bosh.io website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release
manifest
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

Hi,



I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



Thanks,

Sumanth

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh