This describes the situation where phases are merged or phase change assessments are not completed.

In particular I want to describe what happens if you mix ‘Acceptance’ with ‘Completion’

How can this happen?

  • Delivery pressures
  • Fixed deadlines for a complex solution that are too short

How to spot this?

  • Ad hoc requirements
  • Requirements defined in draft form and not signed off before handing over to the supplier
  • Supplementary documentation with slightly different titles

How to avoid this?

  • Have a phase change assessment, whereby documentation is reviewed and signatures are gathered regarding readiness to proceed to the next phase

Why ‘Snakes and Ladders’?

  • Because you have mixed phases you are actively working on an earlier phase while attempting to get to sign off on a later dependency
  • It is not uncommon to achieve small milestones but to drop back in another area
  • Working in this crossover can be quite disorientating

But Agile is just this surely?

  • Agile does not normally involve a buyer / supplier relationship involving million pound tenders

Escalation is one type of flow.

Sometimes it helps to think about it in people terms starting at the beginning of the story

pflow3

The package in wheezy backports dates from January 2014

saltstack_wheezy_backport

 

There are many choices for enterprise monitoring, you may already have server level monitoring in place.

Where an individual process requires inspection over time, a simple monitoring script is an option

One of the trade-offs that you must make when monitoring in detail is sample frequency.

Too frequent and you might cause more issues (large logs or other cruft).

Not frequent enough and you might miss the very thing you are trying to observe.

A basic Python script that logs every 2 minutes to sqlite can be found at the link shown next.

On a server with Python 2 available, and equipped with the process id you wish to monitor (from ps output), you might invoke the script as follows:

python ./pidmem_sample1.py 1234

(where 1234 is the process id of you long running process)

The script will run for 3 months or so, and samples at two minute intervals.

Killing the process being monitored will see the monitoring script exit also.

Bugzilla 4.2 will be end of life in November 2015, so if you are thinking of upgrading, then you might want to take a look at Bugzilla 5.0 ( released in July )

You can follow the ‘Installation and Maintenance Guide’ at bugzilla.readthedocs.org or use a configuration template.

If Ansible is your thing, then the repository at bitbucket.org/wrightsolutions/ansible16bugzilla5 can be used to configure an Ubuntu server ( dedicated or cloud )

In ~/hosts.list for Ansible give your server a name such as ‘myubuntu’
and then clone the repository using:

hg clone ssh://hg@bitbucket.org/wrightsolutions/ansible16bugzilla5

From within the local cloned copy you should be able to see site.yml and then run the following:

ansible-playbook site.yml -i ~/hosts.list -u root -l myubuntu

A video demonstration of the automation is available as follows:

python -m unittest discover

…should work fine when you have set everything up with a bit of forethought

If you see response ‘Ran 0 tests’ then try

touch tests/__init__.py

If you fail to create an empty __init__.py in your tests folder, then Python (rightly) will not recognise it [ as a module ]

Rerun your discover command and if missing __init__.py was holding you up, then you should now be further along.

Along the way you have just learned a little about project structure, and Python requirements generally for modularised code.

netstat grepping

grepping listening ports

Here (above) is an example of grepping the full list of ports shown as LISTEN

My example concentrates on port 80 (apache) or alternatives. Amend to fit your requirements.
Source at Bitbucket below: