Ask HN: What does your deployment workflow look like? - tarikozket
======
arwineap
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

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

------
z0mbie42
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]

~~~
eb0la
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
Nice! on our side, it use a confirm slack button
([https://api.slack.com/docs/message-
buttons](https://api.slack.com/docs/message-buttons))

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

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

