3

Saved bandwith and faster downloads: Artifactory stores the artifacts that are downloaded from maven central. So if another developer needs the same dependencies they don't need to be downloaded again from maven central but instead they can be delivered from the local artifactory instance. This makes downloading faster because company networks are usualy ...


3

When you say "Industry Standard" that's very much going to depend on what industry. You can drop code into production however you want (legally restricted industries obviously being the exemption to this), but the question you should probably be examining is if you should be doing that. I've recently worked on products which range from having ...


2

Got answer from StackOverflow and here is the link to the answer. stage('Test') { parallel { stage("Test_A") { stages { stage("Tests_A") { steps { echo 'from A' } } stage("Archieve") { steps { echo 'from Archieve' } } } } stage("Test_B") { ... } ...


2

Your use case is very simple, so relying on GIT_STRATEGY=fetch is probably sufficient and as you said the default behavior. You should be cautious using artifacts unnecessarily as they are uploaded to the gitlab server. The answer to your question generally depends on a few things, like the size of your repository, network connection, runner executor type, ...


1

Try and add a Stage condition to only run that stage for a specific branch. condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master')) stages: - stage: A ..... - stage: B **condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))** jobs: - job: B1 steps: - script: echo ...


1

In the software industry, it is popular to have staging environments but in order to understand why it is important to understand the reasons why these environments exist in the first place. The production environment is where the company's software meets the company's users. Most companies want their users to be happy, and to receive high-quality software ...


1

I believe both options are viable routes, but my preference is for Option 1 as I like having the "deploy plan" to be only concerned with starting a container using the built image.


1

The "D" in CI/CD means different things to different people, either delivery or deployment. For both groups, it rarely means release everything immediately to production. For the delivery group, the output of CI/CD is an artifact that can be deployed. For the deployment group, there are typically gates in pipelines with either automatic or manual ...


1

It sounds like both of these pipelines are being triggered by the same source commit(s). If that's the case, you should be able to use CI trigger source path filters so that the builds only happen on commits to the relevant code. If a developer does a single commit that is committing changes to both the main application and the package library (which would ...


Only top voted, non community-wiki answers of a minimum length are eligible