Is artifact promotion in this pipeline correct?

Question

I have been tasked with rebuilding my DevOps pipeline and I need some help with a few parts.

We will have our code in BitBucket and have something trigger a server to spin up and validate our PR's. I don't fully understand how to do this at the moment, but its a pretty common pattern so it shouldn't be too bad. We will run our Unit Tests, do some static code analysis (test coverage, complexity, code quality, etc.).

Next we will have a Jenkins job monitoring master. It will run the unit test suite again (I am thinking that this is necessary because when merging the PR's we could introduce some errors possibly). Next it will build the bits and push it to an artifact repository. This will then start the staging test job.

The staging test job will pick up the bits built by the previous job, or allow any user to start it with a valid staging artifact. It will deploy it to a staging environment and then Run the automated tests here. If they pass it will somehow mark this artifact as acceptable. This is my first big question, is it common to move a compiled artifact between repositories to let the team know when it has passed certain quality thresholds?

Next we will have a job that allows anyone to take an artifact that has passed the automated tests and deploy it to some UAT environment where they can do any manual testing or demo's as required. My big question here is how can we mark this artifact as passed/failed?

Finally we have a job that can push an artifact that has passed manual testing out to production. My thinking is that this would allow us to push anything deemed acceptable to go to the customer, and would give us rollback if we build it correctly.

To summarize my questions:

1. How do we mark artifacts that have passed certain stages in the pipeline in an automated fashion?
2. How do we mark artifacts as passing final stages in a manual way?
3. Is this missing anything major or have you run in to issues with a similar pattern?

Answer 1

It depends on the artifact repository you are using but in general, you tag the artifacts in the repository to indicate their state. This can specify it has passed some level of quality gate, some approval, or what ever is required to move through the stages.

I would say you tag the artifact as to it's state, not move between artifact repositories. A single artifact repository can be used to hold the artifacts at multiple versions, and multiple states. This provides a single audit point and a single way of controlling the deployment which can be very helpful.

With tagging of the artifacts you can be clear if they are ready for deployment, and if so to which environments. The tags can be updated in multiple ways, but I would recommend automated processes, such as when an artifact is deployed, the artifact is tagged. When it set of tests pass the end of that marks the artifact as ready. If you have manual testing, that testing will be tracked in some tool or dashboard or approval process, when it is approved, that process should tag the artifact as ready to move on.

Answer 2

I think the way to think about the pipeline is to have an automated system with decision points - gates - that require a human to approve. Your pipeline might have one or many of these gates. There should be people who watch the gates, e.g. QA people waiting for a new build, release management people deciding whether to deploy.

The record of what the pipeline did should be logged somewhere. We are an Atlassian shop, and intend to use JIRA tickets with some special software at these gates. In general we record our DevOps work in JIRA tickets. There are lots of other ways to do the same thing, you could use GitHub, or Jenkins, or CircleCI or Google docs etc.