-
Notifications
You must be signed in to change notification settings - Fork 308
continuous deployment #1138
Comments
We could actually do it directly with Travis CI, with their after_scripts and environment variables. |
@jeromegn No need anymore, http://about.travis-ci.org/docs/user/deployment/ |
@buttscicles Neat! Has been a long time since I looked that up. |
I would not use a third party to deploy on a production site. Much less whenever a change is merged in master unless that is severely controlled. The problems are:
|
Besides the security concerns, there's the less severe but more common case of GitHub and/or Travis going down. We don't want that to hold up deployment for us. |
@whit537 hopefully the CI will use the same script we'd use to deploy. Therefore we could manually deploy. Would be cool to mirror the repo somewhere else, but might be overkill ;) |
We could also run our own Jenkins server and trigger it through a github web hook. If its a commit on a preconfigured branch by a preconfigured github user(s), the jenkins server would deploy on live... Also, I wouldn't have a problem with deployment straight from GitHub provided only trusted people have access to the branch or repo. Automated deployment should never stand in the way of manual updates either. Then the automated system was setup wrong. |
Dropping from Infrastructure. This is advanced infrastructure. |
... as a Service: http://dploy.io/ |
See also #1133. |
Tagging as "blocked", because we'd need to automate DB migrations first, see #2360. |
As the issue isn't user-oriented, reticket to inside. |
When tests pass on a certain branch.
Suggested by @SimonSapin on Twitter.
We'd need to review who has what permissions on the repo.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: