1. Erick Bergsma
  2. PowerBuilder
  3. Tuesday, 5 February 2019 21:29 PM UTC

Hello all...

We need to update our process for application deployment, so that it is SOX Compliant.

The requirement, as I understand it, is that the same files that are tested in the UAT environment are put into PROD environment.  This includes the PB frontend and Oracle backend.

I've implemented this a few different ways in the past, but I thought I would pose the questions here, and see if there are any better solutions.

Accepted Answer
Olan Knight Accepted Answer Pending Moderation
  1. Wednesday, 6 February 2019 19:20 PM UTC
  2. PowerBuilder
  3. # Permalink

We do this with opur Promotion process.

We have a Promotion Form in which each file is listed in the MODIFIED FILES section. That section includes the file name, date, size in bytes:

 

In this way we know precisely which file(s) were promoted and they can be verified at any time.

We also keep each promoted build in its own set of folders.

This system works VERY well.

 

Olan

Comment
  1. Erick Bergsma
  2. Wednesday, 6 February 2019 19:28 PM UTC
Thanks Olan.

Is your application considered a SOX application?

If so, then there needs to be separation of duties, and some sort of audit that says the files that were tested are the ones that go into PROD.



We keep a list, like you do, but I'm looking to see how people implement the SOX requirements.

  1. Helpful
  1. Olan Knight
  2. Sunday, 15 December 2019 20:03 PM UTC
In fact, our app IS SOC-1 compiant, and the Promotion form we use tracks the required informqation.

I've attached a blank Promotion Form and a sample Promotion Form, if you have an interest.



Later -

Olan

  1. Helpful
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Wednesday, 6 February 2019 20:23 PM UTC
  2. PowerBuilder
  3. # 1

Yes, our app absolutely has to be SOX compliant. Our processes ensure this.

 

1. I do the development.
   After my unit and system testing I create the Promotion Form and populate the appropriate sections:
       PBL and Objects changed, list the changes and reference ticket #s. I also enter the object data as per
       my previous post in this thread.

2. Code and promo form is handed off to QA.
    QA populates it's section of the Promo Form. They can accept or reject the build.
         A Rejected build come back to me to fix whatever issues that QA found
         An accepted build  is then promoted to a PRODUCTION_HISTORY archive.
         - Each build is in it's own set of folders which allows us to go back to any previous build for any reason.

3. Once promoted, SYSTEMS then takes the build and moves it towhatever locations are required.
    They then populate their section of the Promo Form.


Olan

Comment
  1. Erick Bergsma
  2. Wednesday, 6 February 2019 20:50 PM UTC
Thanks.

Is there a process to ensure that the fileset QA used to test is the same fileset that SYSTEMS used for PROD?

Not that you would, but "could" you modify the fileset after QA approved it? or is it locked down?



  1. Helpful
  1. Olan Knight
  2. Thursday, 7 February 2019 00:06 AM UTC
The person responsible for the staging of the files into the production platforms and serves is required to check the data in the FILES MODIFIED section of the Promotion Form against the files being moved.



CAN we modify files after being promoted to PRODHISTORY?

Yes, it's physically possible, but the process is to create a new build.

If the files have already been moved into the production environment, we create a new build.

If the files have NOT been moved into the production environment, we COULD change them, but that would require approval from the manager + QA. Easier to make a new build.



Note that QA keeps their copy of the Promotion Form and DEV keeps their copy.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.