Ask HN: What does your development workflow look like? - parfit
======
matt_s
A lot of planning is done before devs get the feature where I work.

1\. Read through 'ticket' (feature/bug/whatever)

2\. If its a change in an area I haven't worked on, read through the code to
figure out what it currently does. If its new think through the problem and
ask any questions. Usually don't want to spend a lot of time on this - coding
will generate questions/clarifications as you go (literally iterative).

3\. Code, inclusive of tests. I occasionally write tests first if it is a well
understood change/fix. If there are common libraries or cross cutting concerns
in the change, run test suites of other projects against change.

4\. Code review plus feedback changes.

5\. Deploy to test env, wait for feedback from testing which includes QA and
possibly other groups.

6\. When testing is done, get approval for deploy and deploy to production.

We have auto-builds after every push to certain branches with test results
hitting chat so we all know if something went bad.

We have the ops pieces in place to deploy whenever. Approvals are usually
gotten in short order (an hour). Some apprehension exists with deploying on a
Friday afternoon. Continuous delivery.

If you're looking for detailed steps in step 3 above, it varies. Sometimes
there are DB changes required, sometimes its an external integration, etc.

------
bsvalley
For a feature for example. Agile with 2-week cycles

1- sprint planning

2- user story definition

3- coding (gathering UX if UI involved, design for backend, then
implementation)

4- testing

5- demo

------
epynonymous
requirements, simple design, coding, code review, pre-commit testing
(automated), post-commit testing (automated), functional/integration testing
(manual), systems testing (somewhat automated), performance testing (mostly
manual).

------
eps
That's an oddly generic question rendering any type of answer largely useless.

~~~
josephhardin
I disagree. Yes most of what each person says will not apply in any given
case, but discussions like this where everyone is just kind of throwing it at
the wall can be useful to try and pick out large trends. Plus as people
discuss specifics of their workflow, individual threads can become more
interesting. Also the more esoteric workflows can be interesting to hear
people describe to put our own systems into context.

