deployment strategy

gcolpart commented

2019-05-01 13:01:49 +02:00

Owner

evocheck need special strategy for deployment.
We can't use Debian stable/testing timing workflow because we improve permanently evocheck. Then I propose to stop using Debian package for evocheck and to deploy with this strategy:

copy new evocheck to evocheck-new.sh
replace evocheck.sh by evocheck-new.sh ONLY if there are less line(s) in output with new script
doing regularly QA work to execute evocheck-new.sh (if exists) and resolve manually warnings to move to evocheck.sh

evocheck need special strategy for deployment. We can't use Debian stable/testing timing workflow because we improve permanently evocheck. Then I propose to stop using Debian package for evocheck and to deploy with this strategy: - copy new evocheck to evocheck-new.sh - replace evocheck.sh by evocheck-new.sh ONLY if there are less line(s) in output with new script - doing regularly QA work to execute evocheck-new.sh (if exists) and resolve manually warnings to move to evocheck.sh

jlecour commented

2019-05-01 13:06:31 +02:00

Owner

here is a small script I've written to compare output :

#!/bin/sh

EVOCHECK_NEW_BIN=${1:-"/root/evocheck-beta.sh"}
EVOCHECK_OLD_BIN=${2-"/usr/share/scripts/evocheck.sh"}

EVOCHECK_NEW_OUT=/tmp/evocheck_new.out
EVOCHECK_OLD_OUT=/tmp/evocheck_old.out

${EVOCHECK_NEW_BIN} > ${EVOCHECK_NEW_OUT} 2>&1
${EVOCHECK_OLD_BIN} > ${EVOCHECK_OLD_OUT}

diff -U 0 ${EVOCHECK_OLD_OUT} ${EVOCHECK_NEW_OUT}

And an Ansible playbook to deploy and run this :

- hosts: all
  vars: 
    evocheckPath: ~/GIT/evocheck/evocheck.sh
    defaultRun: true
  gather_facts: False
  # strategy: free

  tasks:

  - name: Copy evocheck.sh to /root/evocheck-beta.sh
    copy:
      src: "{{ evocheckPath }}"
      dest: /root/evocheck-beta.sh
      mode: "0700"
      owner: root
      force: yes

  - name: Copy evocheck-master.sh to /root/evocheck-master.sh
    copy:
      src: "evocheck-master.sh"
      dest: /root/evocheck-master.sh
      mode: "0700"
      owner: root
      force: yes

  - name: Copy compare-evocheck.sh
    copy:
      src: "compare-evocheck.sh"
      dest: /root/compare-evocheck.sh
      mode: "0700"
      owner: root
      force: yes

  - name: Compare both scripts output
    command: "/root/compare-evocheck.sh /root/evocheck-beta.sh /root/evocheck-master.sh"
    environment:
      VERBOSE: 0
    register: evocheck_comparison
    changed_when: False
    failed_when: False

  - debug:
      var: evocheck_comparison.stdout_lines
    when: evocheck_comparison.stdout != ""

This needs to be adapted to the strategy proposed by @reg

here is a small script I've written to compare output : ```shell #!/bin/sh EVOCHECK_NEW_BIN=${1:-"/root/evocheck-beta.sh"} EVOCHECK_OLD_BIN=${2-"/usr/share/scripts/evocheck.sh"} EVOCHECK_NEW_OUT=/tmp/evocheck_new.out EVOCHECK_OLD_OUT=/tmp/evocheck_old.out ${EVOCHECK_NEW_BIN} > ${EVOCHECK_NEW_OUT} 2>&1 ${EVOCHECK_OLD_BIN} > ${EVOCHECK_OLD_OUT} diff -U 0 ${EVOCHECK_OLD_OUT} ${EVOCHECK_NEW_OUT} ``` And an Ansible playbook to deploy and run this : ```yaml - hosts: all vars: evocheckPath: ~/GIT/evocheck/evocheck.sh defaultRun: true gather_facts: False # strategy: free tasks: - name: Copy evocheck.sh to /root/evocheck-beta.sh copy: src: "{{ evocheckPath }}" dest: /root/evocheck-beta.sh mode: "0700" owner: root force: yes - name: Copy evocheck-master.sh to /root/evocheck-master.sh copy: src: "evocheck-master.sh" dest: /root/evocheck-master.sh mode: "0700" owner: root force: yes - name: Copy compare-evocheck.sh copy: src: "compare-evocheck.sh" dest: /root/compare-evocheck.sh mode: "0700" owner: root force: yes - name: Compare both scripts output command: "/root/compare-evocheck.sh /root/evocheck-beta.sh /root/evocheck-master.sh" environment: VERBOSE: 0 register: evocheck_comparison changed_when: False failed_when: False - debug: var: evocheck_comparison.stdout_lines when: evocheck_comparison.stdout != "" ``` This needs to be adapted to the strategy proposed by @reg

benpro added the

enhancement

discussion

labels 2019-06-06 11:55:44 +02:00

benpro commented

2019-06-06 14:44:29 +02:00

Contributor

Hmm... Maybe we can still keep a package. Packaged or not I propose this method:

Cron to (daily/weekly/monthly) download and install (packaged or not) last evocheck to /usr/share/scripts/evocheck-beta.sh (like spam.sh).
Cron to launch evocheck-beta daily like evocheck but to a special mail address.
QA team (or BAL team) explore the special mailbox from time to time and handle failed checks. When the new evocheck is "clean" they replace /usr/share/scripts/evocheck.sh by /usr/share/scripts/evocheck-beta.sh.

Hmm... Maybe we can still keep a package. Packaged or not I propose this method: - Cron to (daily/weekly/monthly) download and install (packaged or not) last evocheck to `/usr/share/scripts/evocheck-beta.sh` (like spam.sh). - Cron to launch evocheck-beta daily like evocheck but to a special mail address. - QA team (or BAL team) explore the special mailbox from time to time and handle failed checks. When the new evocheck is "clean" they replace `/usr/share/scripts/evocheck.sh` by `/usr/share/scripts/evocheck-beta.sh`.

jlecour commented

2019-08-28 09:50:04 +02:00

Owner

I've just made the mistake to deploy the latest evocheck on (almost) all our stretch servers :/

I'll go back to the proposed strategy for jessie servers.

I've just made the mistake to deploy the latest evocheck on (almost) all our stretch servers :/ I'll go back to the proposed strategy for jessie servers.

jlecour commented

2019-08-28 14:34:09 +02:00

Owner

Since upgraded servers should be treated more loosely than freshly installed servers, we could have a switch in evocheck.sh.

It could be a UPGRADED_SERVER=1 in evocheck.cf.

When a server must be treated as fully compliant, the variable could be removed to set to 0.

@gcolpart @benpro What do yout think about this?

Since upgraded servers should be treated more loosely than freshly installed servers, we could have a switch in evocheck.sh. It could be a `UPGRADED_SERVER=1` in evocheck.cf. When a server must be treated as fully compliant, the variable could be removed to set to `0`. @gcolpart @benpro What do yout think about this?

benpro commented

2019-08-28 15:10:17 +02:00

Contributor

I don't agree.
Of course, some upgraded servers will never be totally compliant. But we should do our best to make these servers as compliant as possible with Evolix standard.
In case of something difficult (e.g related to PHP) to put in conformity, we should manually disable related checks (as we already do).

I don't agree. Of course, some upgraded servers will never be totally compliant. But we should do our best to make these servers as compliant as possible with Evolix standard. In case of something difficult (e.g related to PHP) to put in conformity, we should manually disable related checks (as we already do).

deployment strategy #90