Ask HN: What does your deployment workflow look like?

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

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

Docs at 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.

For us at Phaser (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]

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.

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.

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.)