4

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?

Marcin
  • 181
  • 5
  • 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 http://programmers.stackexchange.com/questions/61726/define-production-ready?rq=1 it's kinda an answer to my question from a different approach. – Marcin Aug 23 '13 at 20:03

3 Answers3

5
  • 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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
1

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
Yusubov
  • 21,328
  • 6
  • 45
  • 71
0

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.

Community
  • 1
Aidan Cully
  • 3,476
  • 1
  • 19
  • 23