7 ms·

Ask HN: What does your deployment workflow look like?

16 points by tarikozket 8y ago

z0mbie42 8y ago
For us at Phaser (https://phasersec.com https://phasersec.com) chatops was a revolution. 1) git push master (Gitlab CI to run tests, builds...) 2) notification received when CI pipelines finished 3) @bot deploy api production (in our messaging app) if errors happen: 4) @bot rollback api [commit]
- simplecomplex 8y ago
  How do you deal with migrating database schema and data?
  - z0mbie42 8y ago
    for the moment, there is a API little downtime to migrate the schema. We use sequelize-cli (event if it's not our ORM) because we can script migrations using javascript which is very powerfull!
- eb0la 8y ago
  We had a similar workflow in a company I worked for some months ago, but for deploy the bot expected upvotes from both development, QA, and Ops.
  - z0mbie42 8y ago
    Nice! on our side, it use a confirm slack button (https://api.slack.com/docs/message-buttons https://api.slack.com/docs/message-buttons)
Annatar 8y ago
1. rpmbuild; 2. upload to the software deployment server; 3. deploy; 4. test the hell out of the software; 5. upload to the peer review tool; 6. passing review, commit. I oversimplify, but everything starts with writing a .spec file for a future package, and then writing everything else and testing the hell out of it and having it peer reviewed before committing.
elechi 8y ago
1) Git push/merge request in gitlab 2) Manual code review (I'm working on getting the CI to work with sonar. Still haven't.) 3). Manual push to Test server. (No idea how to automate deploying to JBoss server on behind a VPN on Windows.)
arwineap 8y ago
All of our code repos follow the same example: 1) PRs create whole environments using master for everything except the repo listed in your PR which uses the PR branch. QA and developers use this for QA 2) Once the PR is accepted the code is merged into master 3) CI builds the code, tags the repo, uploads to s3 as versioned artifact 4) CI checks current version on stg env, deploys new version. CI checks current version on stg env, runs git diff btween the two versions, checks for jira tickets, gets jira ticket summary, and prepares slack / email notifications 5) CI runs tests 6) If tests pass, QA can deploy the release to prd. 7) CI releases to prd, adds released_version to each jira ticket, sends out email/slack notifications (with commit, jira summaries) then runs tests
drakonka 8y ago
I started trying to answer this question, but we produce so many different types of build types (binary, loose file, digital, ISO, and more..) for so many different purposes and audiences (coders, content creators, embedded QA, external QA, 1st party QA, cert, and a mix thereof) that this is actually impossible without typing out a full-on guide of some sort. Extremely rough general flow which does not apply to everything: presub, submit to p4, build code, upload symbols, build data, run tests, run relevant deployment step, register metadata, send-to-one-of-numerous-external-or-internal-partners, and a bunch of support steps inbetween.
meetneps 8y ago
I have built a generic deployment tool that does the following 1. Does dependencies installation 2. Does Code linting 3. Creates a new release folder and gets the entire codebase there. shared/ - for common assets like user upload data and images releases/ 2018060291205/ 2018060300703/ current/ - ll be pointing to the active release. 4. Notify the team on slack, emails and whatever 5. You can rollback at just click of a button and it ll point to one of its previous release. Currently it works well for php. First project is completely free, but only for first 100 signups. Please make this opportunity and signup at http://grandappstudio.com/roll-out?utm_source=news_yc http://grandappstudio.com/roll-out?utm_source=news_yc Docs at http://rollout-docs.grandappstudio.com?utm_source=news_yc http://rollout-docs.grandappstudio.com?utm_source=news_yc Appreciate your feedback, Also we are applying for YC Winter18 batch, if someone could help in reviewing the application and give recommendation would be more than happy. Drop a mail to hello@grandappstudio.com, I would sync up.

16 points by tarikozket 8y ago

For us at Phaser (https://phasersec.com https://phasersec.com) chatops was a revolution. 1) git push master (Gitlab CI to run tests, builds...) 2) notification received when CI pipelines finished 3) @bot deploy api production (in our messaging app) if errors happen: 4) @bot rollback api [commit]

simplecomplex 8y ago
How do you deal with migrating database schema and data?
- z0mbie42 8y ago
  for the moment, there is a API little downtime to migrate the schema. We use sequelize-cli (event if it's not our ORM) because we can script migrations using javascript which is very powerfull!
eb0la 8y ago
We had a similar workflow in a company I worked for some months ago, but for deploy the bot expected upvotes from both development, QA, and Ops.
- z0mbie42 8y ago
  Nice! on our side, it use a confirm slack button (https://api.slack.com/docs/message-buttons https://api.slack.com/docs/message-buttons)

Annatar 8y ago

1. rpmbuild; 2. upload to the software deployment server; 3. deploy; 4. test the hell out of the software; 5. upload to the peer review tool; 6. passing review, commit. I oversimplify, but everything starts with writing a .spec file for a future package, and then writing everything else and testing the hell out of it and having it peer reviewed before committing.

elechi 8y ago

1) Git push/merge request in gitlab 2) Manual code review (I'm working on getting the CI to work with sonar. Still haven't.) 3). Manual push to Test server. (No idea how to automate deploying to JBoss server on behind a VPN on Windows.)

arwineap 8y ago

All of our code repos follow the same example: 1) PRs create whole environments using master for everything except the repo listed in your PR which uses the PR branch. QA and developers use this for QA 2) Once the PR is accepted the code is merged into master 3) CI builds the code, tags the repo, uploads to s3 as versioned artifact 4) CI checks current version on stg env, deploys new version. CI checks current version on stg env, runs git diff btween the two versions, checks for jira tickets, gets jira ticket summary, and prepares slack / email notifications 5) CI runs tests 6) If tests pass, QA can deploy the release to prd. 7) CI releases to prd, adds released_version to each jira ticket, sends out email/slack notifications (with commit, jira summaries) then runs tests

drakonka 8y ago

I started trying to answer this question, but we produce so many different types of build types (binary, loose file, digital, ISO, and more..) for so many different purposes and audiences (coders, content creators, embedded QA, external QA, 1st party QA, cert, and a mix thereof) that this is actually impossible without typing out a full-on guide of some sort. Extremely rough general flow which does not apply to everything: presub, submit to p4, build code, upload symbols, build data, run tests, run relevant deployment step, register metadata, send-to-one-of-numerous-external-or-internal-partners, and a bunch of support steps inbetween.

meetneps 8y ago

I have built a generic deployment tool that does the following 1. Does dependencies installation 2. Does Code linting 3. Creates a new release folder and gets the entire codebase there. shared/ - for common assets like user upload data and images releases/ 2018060291205/ 2018060300703/ current/ - ll be pointing to the active release. 4. Notify the team on slack, emails and whatever 5. You can rollback at just click of a button and it ll point to one of its previous release. Currently it works well for php. First project is completely free, but only for first 100 signups. Please make this opportunity and signup at http://grandappstudio.com/roll-out?utm_source=news_yc http://grandappstudio.com/roll-out?utm_source=news_yc Docs at http://rollout-docs.grandappstudio.com?utm_source=news_yc http://rollout-docs.grandappstudio.com?utm_source=news_yc Appreciate your feedback, Also we are applying for YC Winter18 batch, if someone could help in reviewing the application and give recommendation would be more than happy. Drop a mail to hello@grandappstudio.com, I would sync up.