Using this with an application instead of a module? about semantic-release

[claudiocro]

@gr2m one possibility I think of is to store my archived client to a Amazon S3 bucket like: myapp-v0.0.1.tar.gz. So i would use my S3 bucket instead of the npm archive.

I just started with this awesome library so maybe I miss something.

[boennemann]

Hey @ariporad, thanks for your interest in semantic-release and this issue.

If I understand that correctly both you're client and server are individual packages. Maybe you can try to publish them as (private) npm packages using semantic-release, and then deploy your top-level app that pulls both of them together, whenever a new version gets published.

We are currently experimenting with ideas on how to bring this to applications ourselves and we will share our findings as soon as we have them.

Thanks again,
Stephan

[ariporad]

Thanks!

If I may ask, is there a unified place for discussing these things?

Ari

On Wed, Aug 5, 2015 at 11:23 AM, Stephan Bönnemann <[email protected]

wrote:

Hey @ariporad https://github.com/ariporad, thanks for your interest in
semantic-release and this issue.

If I understand that correctly both you're client and server are
individual packages. Maybe you can try to publish them as (private) npm
packages using semantic-release, and then deploy your top-level app that
pulls both of them together, whenever a new version gets published.

We are currently experimenting with ideas on how to bring this to
applications ourselves and we will share our findings as soon as we have
them.

Thanks again,
Stephan

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

[boennemann]

@ariporad Unfortunately such a thing doesn't exist yet, but I'd be very happy if you could share your thoughts so far in this issue :)

I'll try to come up with a discussion platform and more general information soon-ish.

[ariporad]

Ok.

First of all, you could check out gitter, it's a free chat room.

As for my thoughts, here's what I'm thinking:

1. First of all, my project is in the early stages, so this might change
2. This type of application (where the server just has an API, and the client uses it), is well suited to this project, because semver is important.
3. I'm making this all up as I go, but here's what seems like the most logical way to release such an app (the normal way):

    1. Write the code for the server and client (including any native apps, for example iOS)
    2. Test, etc.
    3. Deploy the server, make 110% sure it works. The server should be backwards compatable.
    4. Once every possible server supports the new version, deploy the web client
    5. Make sure that works
    6. Deploy any other clients.
    7. ???
    8. Profit

1. I would assume that for unit testing the client, you'd test against a known-good server, say the latest commit in master that passed it's tests.
2. Therefore, it seems completely valid that the sign that it's A OK to deploy is when you can run the tests, with the production servers, and have them all pass.
3. Theoretically, if some servers have updated, and other's haven't, that could be a problem. Maybe solve this with a few minute delay.
4. The server could be deployed whenever the tests pass, because, if none of the clients use an api, and it's not in the docs, it (for all intents and purposes), doesn't exist. This might have to be modified for some things, (ie, things that would reveal themselves, but must be kept secret).

Based off all that, it seems like the first step would be allowing for the customization of deployments, for example deploying to heroku instead of npm.

Just my thoughts, feel free to let me know anything I missed.

I can try to open a PR and work on this, if you're interested.

[claudiocro]

I'm also thinking about using semantic-release for my server/client. semantic-release looks very tight couple to npm. Are you planing to abstract this dependency to that other provider / solutions could be used?

[gr2m]

@claudiocro what other providers / solutions would you like to see? Do you mean instead of publishing a module to npm, you'd rather deploy an app to your production server for example?

[boennemann]

@claudiocro

First of all: Because you were talking about having client and server packages. Would it be feasible to have both of these as a private npm package, or hosted on an enterprise registry, and then pull them together into your app and deploy them to your server?

Are you planing to abstract this dependency to that other provider / solutions could be used?

Even though this module/repo is currently called semantic-release, in my thinking this is more like semantic-release-npm, while semantic-release itself is a concept that can be applied to a lot of package managers, providers and other solutions. E.g. there are already solutions popping up for python, gitflow etc.

Time is very limited for me right now, but I'm trying two things.

1. Implement, document and share an architecture model to release and deploy full node apps with semantic-release
2. Write content for semantic-release.org, where we define what the core principles of are, so that it's easy to implement this for any given ecosystem.

[claudiocro]

@boennemann for my current project i'm using the public npm registry, so, no problem.
I just wanted to know if there where future plans towards an abstraction of the npm layer. But thinking of this module as semantic-release-npm makes sense.

If I start a new project (not enterprise) should I use the next branch already?

[boennemann]

@claudiocro Awesome! Yes I can generally recommend to use the next branch, as its pretty much stable already. Here is the roadmap of things we want to add before moving it over to latest: #52

[boennemann]

@ariporad is now working on an alternative git-only implementation, which should make things flexible enough to work with almost anything. If that isn't enough you can still use the about to be created "getLastRelease" hook to implement the logic entirely on your own. This should fully address this issue, so I'm closing. You can track the progress here: #56

[ariporad]

Actually, @boennemann, Currently I'm just working on a git-tags based system for finding the last version, not for publishing via git. (I'm not really sure how that would work anyway).

Could we please re-open this for further discussion?

[boennemann]

@ariporad semantic-release already creates a git tag for you. If you would want to publish using git this is how it would work:

In your package.json instead of

"scripts": {
  "semantic-release": "semantic-release pre && npm publish && semantic-release post"
}

"scripts": {
  "semantic-release": "semantic-release pre && semantic-release post"
}

This way you'd always get a git tag for every relevant change. You could then use Travis's Deployment Tasks to perform certain actions once a tag was created: heroku, aws, modulus, custom script, …

If that doesn't cover what you were asking for please let me know and I'm happy to reopen :)