Workflow for small, rapid-changing and get-it-done-quickly projects [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

开发者_运维问答 Improve this question

I've seen a lot of advice about Git workflow, but it wasn't extremely usable for us. I'd like to get a piece of advice with respect to our situation.

We are a very small web-development company from Russia. A lot of our orders are small web-sites for firms or events. It adds some specifics to our workflow.

• A "release" or "version" makes no sense.
• Most of changes must be done very quickly: get a message about a bug or enhancement/implement/take a look on local machine/deploy/test again in case something was wrong
• In the very beginning there is no polished concept of a specific "feature". Developers get a waterfall of initial documentation, mockups, html layouts and email letters about quick changes falling on their head. (And yes, that is okay for these projects, which are extremely small and need to be changed extremely fast, in the speed of reloading a page). Of course we use tickets in Redmine and all this stuff, but it's extremely hard to use a separate branch for every additional feature and even try not to add two or three small pages/improvements in one commit.
• In most cases, there are only two or three people working on the website. One of them writes only HTML/CSS/JS, another one or two write Python (Django) code. Their responsibilities hardly intersect, I've never seen a single problem with using only one branch for development.
• There is no such thing as a test server (except for the ones on the local machine of every developer). We use test servers for big projects, but I'm not talking about them now.
• We aren't against tests, but a culture of using TDD is very young here.
• Working on a single website is done within a month or two, after that we only make small enhancements or fix small bugs and we do it quite rarely.

So it goes like this:

1. Developers gets an urgent task (or several) or selects one or two from the ticket system.
2. He makes changes and tests them.
3. "hg pull -u"
4. "hg commit"
5. "hg push"
6. deploy (Actually, steps 3-6 are done with the fabfile.py. Of course it asks for commit message)
7. Proceed to other tasks (and maybe other projects, we have lots of them).

I don't find our process very broken. But I think it can be improved. I don't have great experience in development. Neither do my colleagues (even worse, I'm the dev lead and I'm the most experienced).

We are trying to use "best practices" for best of our works, but we find them too complicated for small websites. With small websites, problems with "legacy" code aren't very annoying, so we prefer speed and ease. I want you to take it into account while advising me something.

So, any observations or remarks? Please share your experience. Thank you.

---

A list of things we'd like to improve:

• "Safety" of making changes somehow
• Time managing - we'd like to see which tasks we're spending more times
• Easiness of adding/changing people working on a project
• Reducing excessive and unnecessary communication

---

Based on what you wrote - the only thing I would change for your process is do just 1 feature per commit. This will make it much easier to trace things in the future.

---

If your process is working for you, keep using it.