Automation

[markthethomas]

What're we thinking? Should provide at least a build step, dockerfile, etc.

"nothing forces us to understand a process better than trying to automate it." -- more quote fun

[Ephapox]

Not sure about the other guys but I'm going to need some primer on terminology.

Would this be things like test runners, npm scripts, build systems (gulp? broccoli?), CI. When you say dockerfile are you referring to being able to spin up instances of the application?

I also have a quote from some guy I forget the name of, "start simply, simply start"

[markthethomas]

@Ephapox oh sorry, I wrote that really quickly and it wasn't super clear — my bad! Also, that guy whose name you forgot sounds like weirdo. Definitely wouldn't take anything he says seriously.

I'm thinking we should provide a buildstep for the app itself and for the runtime. The former would be transpilation of both server/client probably using babel and webpack. This would be mainly for front-end though — not super sure what the best way is for ES6 server side.

So:

Build (app source) --> gulp, webpack, broccoli, rollup.js --> es5-friendly ES6 code that's been minified, had tree-shaking done, etc. We will set up runners for tests. I really like sindresorhus/ava and sinonjs/sinon bc they're simple, fast, and keep you from doing too much dumb stuff. Also no implicit globals like in mocha. For React I love Enzyme, but that's down the road and we can figure that out later.

^^^^^--runs on--vvvvv

Build (runtime/ OS): Docker/Heroku, &c.: the tools that either help create (in the case of Docker) or allow the app to run. So this would be like devops kind of stuff, but is good to provide so people could easily get a docker container running or something. Also great for CI testing

Docker overview:

I'm going to shamelessly steal from myself:

What is Docker, Anyway?

Docker's homepage describes Docker as follows:

"Docker is an open platform for building, shipping and running distributed applications. It gives programmers, development teams and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications."

Put differently, Docker is an abstraction on top of low-level operating system tools that allows you to run one or more containerized processes or applications within one or more virtualized Linux instances.

Advantages of Using Docker Before we dive in, it's important to stress the potential usefulness of Docker in your software development workflow. It's not a "silver bullet", but it can be hugely helpful in certain cases. Note the many potential benefits it can bring, including:

Rapid application deployment Portability across machines Version control and component reuse Sharing of images/dockerfiles Lightweight footprint and minimal overhead Simplified maintenance

Docker lets you create containerized virtual machines that can be created in pretty much however way you want. One way you can configure Docker builds is through Dockerfiles, which pretty much just let you step through creating whatever environment your app needs to run. Here's a sample one from Charityware:

#   ____ _                _ _
#  / ___| |__   __ _ _ __(_| |_ _   ___      ____ _ _ __ ___
# | |   | '_ \ / _` | '__| | __| | | \ \ /\ / / _` | '__/ _ \
# | |___| | | | (_| | |  | | |_| |_| |\ V  V | (_| | | |  __/
#  \____|_| |_|\__,_|_|  |_|\__|\__, | \_/\_/ \__,_|_|  \___|
#     _    ____ ___  __     ___ |____   ___
#    / \  |  _ |_ _| \ \   / / | / _ \ / _ \
#   / _ \ | |_) | |   \ \ / /| || | | | | | |
#  / ___ \|  __/| |    \ V _ | || |_| | |_| |
# /_/   \_|_|  |___|    \_(_)|_(_\___(_\___/
#

# ____    __    ____  ___       __       __              _______
# \   \  /  \  /   / /   \     |  |     |  |            |   ____|
#  \   \/    \/   / /  ^  \    |  |     |  |      ______|  |__
#   \            / /  /_\  \   |  |     |  |     |______|   __|
#    \    /\    / /  _____  \  |  `----.|  `----.       |  |____
#     \__/  \__/ /__/     \__\ |_______||_______|       |_______|

FROM debian:jessie

# Replace shell with bash so we can source files
RUN rm /bin/sh && ln -s /bin/bash /bin/sh

### Set environment variables ###
ENV appDir /var/www/app/current
ENV NODE_ENV production
ENV PORT 80

# Run updates and install deps
RUN apt-get autoclean
RUN apt-get autoremove
RUN apt-get update

RUN apt-get install -y -q --no-install-recommends \
    build-essential \
    curl \
    gcc \
    make \
    nginx \
    sudo \
    && rm -rf /var/lib/apt/lists/* \
    && apt-get -y autoclean

RUN apt-get -y autoclean

ENV NVM_DIR /usr/local/nvm
ENV NODE_VERSION 5.10.0

# Install nvm with node and npm
RUN curl -o- https://foo.bar.io/install/nvm/install.sh | bash \
    && source $NVM_DIR/nvm.sh \
    && nvm install $NODE_VERSION \
    && nvm alias default $NODE_VERSION \
    && nvm use default

ENV NODE_PATH $NVM_DIR/versions/node/v$NODE_VERSION/lib/node_modules
ENV PATH      $NVM_DIR/versions/node/v$NODE_VERSION/bin:$PATH

### Set the work directory
WORKDIR ${appDir}
RUN mkdir -p /var/www/app/current

# Set things up
ADD package.json ./
RUN npm install -g pm2 && npm install --production

#Add app files
ADD . /var/www/app/current

RUN service nginx restart

EXPOSE 80

CMD ["pm2", "start", "processes.json", "--no-daemon", "--merge-logs"]

[markthethomas]

@Ephapox sorry, that was pretty long. :hushed:

[jamesdoc]

Have you looked in to Otto by Hashicorp Mark?

Sent from my phone, sorry for a short response On 2 Apr 2016 08:32, "Mark Thomas" notifications@github.com wrote:

@Ephapox https://github.com/Ephapox sorry, that was pretty long. [image: :hushed:]

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/markthethomas/quill/issues/8#issuecomment-204666537

[markthethomas]

oh yeah! I remember seeing that. It's the new & improved vagrant, no? Looks legit. Would definitely want to look into that for quill. :+1:

[Ephapox]

@markthethomas no need to apologize, the QnA is the best way for us to see what this is going to look like.

Here's what you wrote for Samuels dummies

Build Systems

• Runtime/OS
  • Docker for builds
  • Quickly get the app running anywhere.
  • Circle CI for CI
  • Run an instance of the app and run tests/coverage and see the status of the build.
  • Get cool badgez on our github page (unless the build is failing, then it's not cool).
• Application source
  • Testing
  • Test runner (runs the test, duh)
    • ava
  • Mocks (easily make mock function calls and create objects to use as values for use in tests)
    • sinon
  • ES6!
  • babel
  • Module loading (clear syntax for managing application modules and lazy loading modules)
  • rollupjs
  • webpack
  • requirejs
  • browserify
  • Task runners (automates most of the stuff mentioned above)
  • gulp
  • broccoli

Questions

• Are assertion libraries still a thing?
• Include git hooks for clear commit messages and issue tracking?

[markthethomas]

I love the outline! I should just stick to writing those and forget all the longer stuff :) You've nailed it.

As for that last two:

1) I'm not opposed to assertion libs, but I've found that you really only need some primitives, usually:

• truthy, falsy
• true/false
• strict equality, deep equality
• throws/notThrows ...and a few more probably, just variations on the above though. Chai and company are ok, but I get a little hesitant to do things like expect(foo).length.to.be(3) when you could just as easily write (in https://github.com/sindresorhus/ava or tape or another simple testing lib) t.is(foo.length, 3). Most unit tests work on some sort of expression, so IMO just evaluating an expression (which is what you're actually testing in one sense) and then seeing if it's truthy/falsy/&c. is more simple & flexible than having to chain 5 methods off of an expect assertion. Also, as an über stupid-small detail, chaining.like.this.is.a.little.slower.due.to.how.the.object.lookup algorithm works. I'll have to jsperf it to confirm though.

2) Actually haven't done a ton w/ commit hooks — enlighten me? :D We use git flow at work and it's great, but I don't think that's the same category as using git hooks, rt? Sam's turn :shipit:

[Ephapox]

1. Oh man I totally agree with you on that. Although I can see why people might like the readability of something like mocha I personally would not like to deal with the barrier of having to look up assertions. I would much rather have a short list of methods that cover any use cases we would encounter.

2. I've only implemented them via doing this super helpful egghead tutorial (How to write an open source javascript library). All I really know is that we can run certain scripts pre/post commit and pre/post push and those scripts can block commits or pushes from occurring if some requirement is not meant. Those requirements can be test coverage, test passing, a commit message style. The scripts can also be associated with a user story in asana/jira/trello.

   An example is that at my work all the engineers follow a commit and branch naming convention that involves putting the jira ticket number in the branch name/commit message. Our git hook will then put the commit right into the jira ticket along with the diffs. If the convention isn't followed then it blocks the commit.

   I don't know if git hooks might add unnecessary complexity to this project or if it's even necessary on a project this small (for now...) but that's as much as I could really say on that.

[jamesdoc]

On gulp... isn't that going away with NPM scripts now? We've removed it from our (very simple) build process.

This is where I started: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

[markthethomas]

@Ephapox sounds cool! I'll check out the eggehead tutorial. I think we should definitely look into it as we go along, I'd love to see how it might fit in.

On a side note, have you guys liked JIRA? We're sort of considering it for our team at work. We're moving really fast right now, so it's hard to dedicate a lot of time to something like that, but I know our VP is thinking about it long-term.

[markthethomas]

@jamesdoc def. would love to keep gulp out of the picture if possible. npm scripts are definitely a great way to replace and IMO better mentally. The funny thing I've found so far is that most of the time you just end up swapping gulp tasks w/ webpack run by npm, which is definitely a step-up, but is more-or-less symmetrical overall (task-runner that does work w/ plugins is replaced by much simpler task-runner that does syscalls to binaries or other tools you have, sometimes based on plugins (if webpack)).

Really nice not to have to wrangle tasks, though, let's try to avoid gulp & company if possible :+1:

[jamesdoc]

On Jira, we're using it at the V&A. It is functional, but a but of a pain. Yet to find anything better though.

[Ephapox]

Can't really speak to other ticketing systems but it seems to be sufficient for our purposes. It can get a little annoying if not understood by the team using it since it has a lot of notification features. How you implement it might depend on whether it would be used exclusively by certain teams or used across the company and all departments.

I honestly don't know what like half the buttons or input fields are for. All I really do is change the ticket status, log work, download assets, and communicate via comment section.

[jamesdoc]

Depending on the size/scale of the project I quite like Trello as a ticket management system.

[kknopper]

@markthethomas we use jira at my job. it works pretty well, but like mentioned above it can get kind of annoying, depending on if people on the team use it incorrectly. I've tried trello too, but its more for workflow management than tickets, i guess you could set it up that way though.

On the build process, don't really see the full benefit of using npm scripts. It does look a tad shorter to write, but a bit more confusing. Don't really see the problem with gulp having a bunch of dependencies either, as most of them are just for development anyway.