I am finishing up a decently sized Python/Shell project, and I'm wondering if there's a 'best practice' list of things to do when finishing up development.

So far I've done:

  • pylint
  • pycallgraph
  • grep'ed for :TODO: and :FIXME:
  • find orphan code
  • some more documentation
  • install scripts for client and server
  • make sure comments match the reality (before I forget the finer points)

What other things do you do, generally, or Python-specific?

  • Are you working along or in a team? Does your company have a QA department? – Doc Brown Aug 23 '13 at 19:25
  • Nope, I am not a coder, this is not a coding shop. This is an internal development by a systems/security guy who happens to code. – Marcin Aug 23 '13 at 19:47
  • Well, you code for production, so you are in the role of a coder now. And from your comment I guess you work/code alone. – Doc Brown Aug 23 '13 at 19:57
  • 1
    Correct. I also found programmers.stackexchange.com/questions/61726/… it's kinda an answer to my question from a different approach. – Marcin Aug 23 '13 at 20:03
  • make sure you have enough automatic tests
  • run them!
  • also test things for which you don't have automatic regression tests (for example, your install scripts)
  • and make sure you have everything checked in into your SCCS (test that by checking everything out on a clean machine and see if there is something missing)
  • make sure version numbers are up-to-date
  • update your change log (the document for your client, not the comments in your SCCS)
  • update your list of open issues / list of requirements for the next release / backlog / issue tracker (whatever you use for this purpose)

And one thing: IMHO some of the things you mentioned should be always in order at the end of the day - adding or correcting comments only before going to production is far too late. Make your comments match reality immediately, whenever you change a function, later you will forget about it.


Spend good amount of time on back-up plans to roll-back deployments in the case of failure or un-expected events.

Back-up :

  • Prepare a checklist and add items to it
  • Make sure you have a back-up plans for Database roll-back, scripts, etc.
  • Remove logging code or check the production/testing setting of the app.
  • Simulate the worse scenario of deployment
  • Check the failing points of the overall system (network connectivity, firewalls, etc..)
  • Prepare a roll-back scenario and simulate it

I haven't seen this listed explicitly (though Doc Brown's answer touched on it, regarding version numbers), but IMHO the single most important part to get right in a release process is the Configuration Management. You should to be able to identify exactly what artifacts were deployed, and be able to reproduce those artifacts on demand from source.

If a customer comes to you with a bug, you'll really want to know precisely the source under which the bug was created.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.