<p>Please below where I address specific questions.</p>

<blockquote>
  <p>2: do we need to use docker? if not how it should be done</p>
</blockquote>

<p>By using Docker you can automate the configuration of your server images as well as application images to use to deploy to staging and into production.</p>

<p>Docker use standard images that you build on by adding your custom software installation and commands into the image. As Docker is mean to run one service per container (a running image), you are also having the benefit of beginning to decouple your applications into microservices.</p>

<p>Take a look at Docker "images", "containers" and "Dockerfiles", to get an understanding of the principles and architecture.</p>

<p>The benefit of automating your infrastructure with Docker images that are created with Dockerfiles are many:
- Your setup becomes less prone to manual mistakes.
- Faster spin-up of services (your app or software) in staging, and also in production. You can batch the spinning up of containers.
- Simpler overview of the tasks involved to setup your servers. As you begin to write Dockerfiles you are taken down the thought process of both development and operations, because you have to write sequential commands for the setup of the servers. That leads to a deeper understanding of your own pipeline - And how it can be improved.</p>

<blockquote>
  <p>3: what setup can we do to reduce manual work? our problem is not needing approvals but automating as much as we can since we don't have IT/DevOps guy and neither QA.</p>
</blockquote>

<p>Try to embrace the KISS principle - "Keep It Simple, Stupid". Start small with making a list of the manual tests that you perform on a routinely basis.</p>

<p>Are these tests related to testing REST endpoints and/or load testing? Then take a look at tools such as JMeter to codify your tests that can be saved as files and triggered in for instance Jenkins (with the Performance plugin). You can load your tests in CSV format and call JMeter from within Jenkins.</p>

<p>These are just a couple of suggestions (from many possibilities). I hope this inspires you for your CI/CD setup.</p>

CC BY-SA 4.0
2019-09-21T08:07:31.927Z
2019-09-21T08:07:31.927Z
Paul-Beyond
<p>It might not be obvious now, but usually as projects advance full regression costs (resources/time) grow much faster than static analysis ones. </p>

<p>You'll also find that static analysis alone isn't a sufficiently solid bug gate, it must be complemented with regression testing as well.</p>

<p>So I'd place the full regression <strong>after</strong> the static analysis in the CI/CD pipeline - I wouldn't want to waste full regression costs on code which doesn't even pass static analysis.</p>

<p>Down the road you'll probably find that running full regression and/or full static analysis in earlier pipeline stages can easily become bottlenecks:</p>

<ul>
<li>if you block other commits while waiting for the run results you'd slow down the commit rate</li>
<li>if you allow other commits while a run is in progress they'll change the repository context potentially invalidating the earlier run results (for example you can't immediately fix a runtime bug uncovered by the run if the subsequent commit that happened in the meantime causes a build time breakage).</li>
</ul>

<p>Addressing these bottlenecks usually means splitting such runs across 2 major  functional stages (each one can actually consist of multiple sub-stages and/or steps):</p>

<ul>
<li><p>the <strong>(pre-)integration</strong> stage(s), which execute <strong>subsets</strong> of these runs in the earlier pipeline stages:</p>

<ul>
<li>shorter - to maintaining a sufficiently high commit rate and avoiding bottlenecks</li>
<li>the target quality level is below deployment, but high enough to keep development flowing</li>
<li>fixing regressions detected in these stages has a high priority. </li>
<li>it's possible to use such runs to gate commits/merges in order to <strong>prevent</strong> rather than <strong>detect and fix</strong> regressions, in which case these would actually be <strong>pre-integration</strong> stages</li>
</ul></li>
<li><p>the <strong>post-integration</strong> stages, executing the longer/full regression and/or static analysis runs: </p>

<ul>
<li>the goal here would simply be increasing the quality to deployment levels (i.e. blocking the actual deployment if not met)</li>
<li>regressions detected at this stage aren't blocking for development, fixing them is a lower priority</li>
</ul></li>
</ul>

CC BY-SA 4.0
2019-09-14T15:47:32.603Z
2019-09-14T15:47:32.603Z
Dan Cornilescu
<p>I started a project with a small team (3 people ) and we had to hack a lot and built a big application with no unit tests, relying only on manual. Now we have a huge technical debt and we started implementing CI/CD. Our goal is to start doing cypress tests everywhere, then some unit tests and refactoring the code as well as implementing static analysis tools on the Ci/CD pipeline:</p>

<p><a href="https://i.sstatic.net/nfGhw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/nfGhw.png" alt="enter image description here"></a></p>

<p>Our idea is that we will not have any local environment but just server-based. So developer push code to Gitlab, Gitlab runner in Digital Ocean push the repository to staging server, Developer debugs in Digital Ocean using Local Cypress Runner and his own modifications, if he breaks something or forgets to do a full regression test a command-line test regression runner is triggered BEFORE the second deployment so it doesn't allow the code to pass to the deployment/production server.</p>

<p>Questions
1: do we need to separate deployment environment from staging in 2 droplets? can we achieve this configuration without major headaches in the same droplet?</p>

<p>2: do we need to use docker? if not how it should be done</p>

<p>3: what setup can we do to reduce manual work? our problem is not needing approvals but automating as much as we can since we don't have IT/DevOps guy and neither QA.</p>

<p>Note: the first stage is to implement full regression, the second stage is to implement code quality tools (static analyzers) such as sonarqube, phpStan, etc.</p>

<p>Stack: LAMP stack with PHP Codeigniter and vanilla JS.</p>

CC BY-SA 4.0
2019-09-14T11:04:53.593Z
If possible, I would use Docker. Also, use Docker to specify build and (smoke) test environment. Check the manual for multistage Docker files.
Ta Mu
<continuous-integration><continuous-deployment><cicd><gitlab-ci-runner>
Best way to create a Ci/CD pipeline to reduce bugs and facilitate refactor
Daniel Vianna
# Best way to create a Ci/CD pipeline to reduce bugs and facilitate refactor

(Asked by: username_0 on 2019-09-13)

I started a project with a small team (3 people ) and we had to hack a lot and built a big application with no unit tests, relying only on manual. Now we have a huge technical debt and we started implementing CI/CD. Our goal is to start doing cypress tests everywhere, then some unit tests and refactoring the code as well as implementing static analysis tools on the Ci/CD pipeline:

[![enter image description here](https://i.sstatic.net/nfGhw.png)](https://i.sstatic.net/nfGhw.png)

Our idea is that we will not have any local environment but just server-based. So developer push code to Gitlab, Gitlab runner in Digital Ocean push the repository to staging server, Developer debugs in Digital Ocean using Local Cypress Runner and his own modifications, if he breaks something or forgets to do a full regression test a command-line test regression runner is triggered BEFORE the second deployment so it doesn't allow the code to pass to the deployment/production server.

Questions
1: do we need to separate deployment environment from staging in 2 droplets? can we achieve this configuration without major headaches in the same droplet?

2: do we need to use docker? if not how it should be done

3: what setup can we do to reduce manual work? our problem is not needing approvals but automating as much as we can since we don't have IT/DevOps guy and neither QA.

Note: the first stage is to implement full regression, the second stage is to implement code quality tools (static analyzers) such as sonarqube, phpStan, etc.

Stack: LAMP stack with PHP Codeigniter and vanilla JS.

**Tags:** continuous-integration, continuous-deployment, cicd, gitlab-ci-runner

> **Comments:**
> **username_1**: If possible, I would use Docker. Also, use Docker to specify build and (smoke) test environment. Check the manual for multistage Docker files.  

---

## 2 answers

### Answer by username_3 on 2019-09-14. Score: 3 | Accepted answer

It might not be obvious now, but usually as projects advance full regression costs (resources/time) grow much faster than static analysis ones.

You'll also find that static analysis alone isn't a sufficiently solid bug gate, it must be complemented with regression testing as well.

So I'd place the full regression **after** the static analysis in the CI/CD pipeline - I wouldn't want to waste full regression costs on code which doesn't even pass static analysis.

Down the road you'll probably find that running full regression and/or full static analysis in earlier pipeline stages can easily become bottlenecks:

* if you block other commits while waiting for the run results you'd slow down the commit rate
* if you allow other commits while a run is in progress they'll change the repository context potentially invalidating the earlier run results (for example you can't immediately fix a runtime bug uncovered by the run if the subsequent commit that happened in the meantime causes a build time breakage).

Addressing these bottlenecks usually means splitting such runs across 2 major functional stages (each one can actually consist of multiple sub-stages and/or steps):

* the **(pre-)integration** stage(s), which execute **subsets** of these runs in the earlier pipeline stages:

  + shorter - to maintaining a sufficiently high commit rate and avoiding bottlenecks
  + the target quality level is below deployment, but high enough to keep development flowing
  + fixing regressions detected in these stages has a high priority.
  + it's possible to use such runs to gate commits/merges in order to **prevent** rather than **detect and fix** regressions, in which case these would actually be **pre-integration** stages
* the **post-integration** stages, executing the longer/full regression and/or static analysis runs:

  + the goal here would simply be increasing the quality to deployment levels (i.e. blocking the actual deployment if not met)
  + regressions detected at this stage aren't blocking for development, fixing them is a lower priority


---

### Answer by username_2 on 2019-09-21. Score: 0

Please below where I address specific questions.

> 2: do we need to use docker? if not how it should be done

By using Docker you can automate the configuration of your server images as well as application images to use to deploy to staging and into production.

Docker use standard images that you build on by adding your custom software installation and commands into the image. As Docker is mean to run one service per container (a running image), you are also having the benefit of beginning to decouple your applications into microservices.

Take a look at Docker "images", "containers" and "Dockerfiles", to get an understanding of the principles and architecture.

The benefit of automating your infrastructure with Docker images that are created with Dockerfiles are many:
- Your setup becomes less prone to manual mistakes.
- Faster spin-up of services (your app or software) in staging, and also in production. You can batch the spinning up of containers.
- Simpler overview of the tasks involved to setup your servers. As you begin to write Dockerfiles you are taken down the thought process of both development and operations, because you have to write sequential commands for the setup of the servers. That leads to a deeper understanding of your own pipeline - And how it can be improved.

> 3: what setup can we do to reduce manual work? our problem is not needing approvals but automating as much as we can since we don't have IT/DevOps guy and neither QA.

Try to embrace the KISS principle - "Keep It Simple, Stupid". Start small with making a list of the manual tests that you perform on a routinely basis.

Are these tests related to testing REST endpoints and/or load testing? Then take a look at tools such as JMeter to codify your tests that can be saved as files and triggered in for instance Jenkins (with the Performance plugin). You can load your tests in CSV format and call JMeter from within Jenkins.

These are just a couple of suggestions (from many possibilities). I hope this inspires you for your CI/CD setup.


---

