How does modern CI/CD work, where features need to be manually tested (or why there are almost no manual features for Gitlab’s pipelines)?

Hi, I started wondering how could my team move to Gitlab's CI environment and found that some features were completely unavailable which seems to be intentional!

Quick bg: the project I'm working on consists of >10 microservices. While we have some automated testing, every feature is manually tested by QAs on branch(es) by deploying the entire stack on one of VMs from our pool. Only then the feature branch(es) is merged into a develop)

Now, these stage environments are built on Jenkins using parameterized job – we basically select branch of each microservice and hit run, and then an Ansible playbook kills existing vm on a pool, creates a new one and installs the whole project.

When I started investigating Gitlab's pipeline features, I found out that a similar parameterized job does not exist, and basically the only remotely similar feature is to manually overwrite default parameters in a pipeline, and there you have to both write name and full value of the parameter by hand, no handy branch dropdowns.

Gitlab seems to be both mature environment and serious about replacing pretty much all the Devops stack. The decision to remove manual input from pipelines seems intentional. If so, how does the manual feature testing happen?

submitted by /u/rafalsz
[link] [comments]

from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/83Zxoaz

Leave a comment

Design a site like this with WordPress.com
Get started
search previous next tag category expand menu location phone mail time cart zoom edit close