Skip to content

Latest commit

 

History

History
87 lines (48 loc) · 4.16 KB

Workflow.md

File metadata and controls

87 lines (48 loc) · 4.16 KB
Raw
// drafting...

Intro

DevProgress is a team of kick ass developers using their skills and expertise to create tools that will help elect Hillary Clinton and other Democratic and progressive candidates.

Here is outline of our standard break down of tasks, pushing code and releasing to production.

Tooling

Tech stack.

Our standard baseline code is lightweight client only react web apps on gh-pages.

  • Javascript.
  • React. Javascript driven css.
  • Webpack npm dev and build.
  • Automated Testing (?)
  • Continuous Delivery (?)

Trello

Trello is used to track all our projects at a high level.

It's not something we use to track tasks at a project level.

This is where ideas and campaign requests are first created.

Developers can visit the trello board to see what projects are new, inflight and done.

Slack

Slack is our discussion forum for all projects.

This is where technical decisions get made.

Developers can use slack to join the conversation around any particular project and discover how they can help.

Github

Once a technical approach has been agreed upon in slack the collaboration moves to github to track tasks, branch and code review.

Branching Strategy

The tip of the master branch of the project is what goes to production. To contribute, use fork + pull request workflow. Avoid creating your own branches in the project repository.

Code Reviewing

All code needs to be reviewed before it is merged back to the master branch.

  1. Pull the branch in question.
  2. Run it locally.
  3. Inspect the code changes and offer any tips on how it may well be improved
  4. If you're happy with it then add a "+1" comment.

With two "+1" comments on any given Pull Request the original creator is free to approve the Pull Request.

Consider switching your master branch to be a protected branch, which will make reviews mandatory.

Task breakdown & Issue Tracking

We create github issues. Anyone is free to add issues to any given Project.

Once a developer begins working on an issue they assign themselves to it so others know it is in progress.

Use milestones to create and track burndown (aka deadline-based) lists of issues.

Testing and Continuous integration

Consider developing a testing plan for your project. What are the things that matter and need to be checked twice before pushing to prod? For example, the project i-like-hillary-but is mostly articles with links, so an html-proofer is a good way to make sure the links lead the user to the right places.

A healthy project could use a hygiene robot that watches over it. We use Travis CI and it's really easy to set up. There are straightforward guides available.

You need to be an admin of the project in order to flip the Travis CI switch. Ask for the privilege or ping one of the folks on #peeps-infra.

Deploying

We use Github Pages for deployment. To set up:

  1. Set up your development workflow to write production files to the /docs directory. Though the name seems like a bit of a misnomer, using it provides the least cumbersome Github Pages deployment option. Here are some examples:

  2. Jekyll on i-like-hillary-but.

  3. React+WebPack on debate-bingo.

  4. Follow instructions for publishing Github Pages site from a /docs folder on your master branch.

  5. Whenever you're ready to deploy, write the latest production files into /docs, commit them to master, and follow the usual code review process. It may take a bit of time for Github Pages to update.