ods3-features

outline.md

✂️ Get rid of that boilerplate!

From:

def final projectId = 'foo'
def final componentId = 'bar'
def final credentialsId = "${projectId}-cd-cd-user-with-password"
def dockerRegistry
node {
  dockerRegistry = env.DOCKER_REGISTRY
}

@Library('ods-jenkins-shared-library@2.x') _

odsPipeline(
  image: "${dockerRegistry}/cd/jenkins-slave-golang:2.x",
  projectId: projectId,
  componentId: componentId,
  branchToEnvironmentMapping: ['master': 'dev']
) { context ->
  stageScanForSonarqube(context)
  stageStartOpenshiftBuild(context)
  stageDeployToOpenshift(context)
}

To:

@Library('ods-jenkins-shared-library@3.x') _

odsComponentPipeline(
  imageStreamTag: 'ods/jenkins-agent-golang:3.x',
  branchToEnvironmentMapping: ['master': 'dev']
) { context ->
  odsComponentStageScanWithSonar(context)
  odsComponentStageBuildOpenShiftImage(context)
  odsComponentStageRolloutOpenShiftDeployment(context)
}

♻️ Reusing container images

https://www.opendevstack.org/ods-documentation/opendevstack/3.x/jenkins-shared-library/component-pipeline.html#_odscomponentstageimportopenshiftimageorelse

Why?

• Shorten build time
• Reduce resource usage in cluster
• Avoid errors / differences between images

How?

• ODS uses a Git Branch based approach (Branch to Environment Mapping)
• How to tell ODS which image should be promoted where?
• Idea:
  • Tag images with Git SHAs
  • If we build the exact same Git SHA, we also want the same resulting image
  • Ok, but how do we ensure we have the same Git SHA? -> Changing the merge strategy

	  A---B---C feature/x
	 /
    D---E---F---G master

--no-ff

	  A---B---C feature/x
	 /         \
    D---E---F---G---H master

--ff-only

	   A---B---C feature/x
          /       A'--B'--C' feature/x
	 /       /
    D---E---F---G---A'--B'--C' master

https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---ff

Advantages:

• Git SHA stays the same across branches (works well with branch to env mapping now)
• No “unnecessary” commits
• Avoids loosing commits in production

Example

odsComponentStageImportOpenShiftImageOrElse(context) {
    stageLint(context)
    stageBuild(context)
    odsComponentStageScanWithSonar(context)
    odsComponentStageBuildOpenShiftImage(context)
}

imagePromotionSequences: ['dev->test', 'test->prod']

Caveats

🍬 PR decoration

Get comments on your PR when you push code - bring SQ closer to dev experience.

https://www.opendevstack.org/ods-documentation/opendevstack/3.x/jenkins-shared-library/component-pipeline.html#_odscomponentstagescanwithsonar

How?

Caveats

• PR must exist before you run the pipeline
• If you run the pipeline again, you might not build, see above section!

🚀 Deploying OpenShift Templates

https://www.opendevstack.org/ods-documentation/opendevstack/3.x/jenkins-shared-library/component-pipeline.html#_deploying_openshift_resources_from_source_code

Why?

• Software-defined everything
• Reviewable, Traceable, Reproducable
• Allow to make infrastructure and application changes at the same time
• Avoid mismatch between environments
• Ability to start with empty projects (e.g. in other cluster)

How?

tailor -n foo-dev export -l app=foo-bar > openshift/template.yml

Caveats

• No more editing in the UI
• Remove ImageTrigger to avoid double rollout (but set ImagePullPolicy: Always!)

💎 Various bits and pieces

withOpenShiftCluster

withOpenShiftCluster(context, [apiUrl: "https://api.example.com", credentialsId: "foo-cd-sa-example"]) {
  // Your code here, e.g.
  // sh "oc whoami --show-server" // prints https://api.example.com
}

Jenkins

• Force plugin versions - every image update also updates / sets plugin versions
• One Dockerfile for both CentOS and RHEL
• FROM image directly from registry (instead of sourcing from openshift namespace and having to update it there regularly)
• No image triggers on the deployments anymore (con: need to refresh manually, pro: not bringing down the cluster due to simulatneous restarts)
• HTTP proxy config (also for Nexus and SonarQube!)

Webhook Proxy

• Update pipeline when e.g. Jenkinsfile path changes
• Don't create pipeline for tags (but possible to configure)
• Support more Bitbucket events (pr:opened and pr:deleted)
• Better error logs

Makefile targets / Automation

→ make help

Usage:
  make <target>

Targets:

  prepare-bitbucket-repos             Prepare Bitbucket repos (create project and repos).
  prepare-local-repos                 Prepare local repos (fetch changes from Bitbucket).
  sync-repos                          Sync repos (fetch changes from GitHub, and synchronize with Bitbucket).

  prepare-config                      Update local sample config sample and run check against local actual config.

  install-ods-project                 Setup central "ods" project.

  install-jenkins                     Install or update Jenkins resources.
  apply-jenkins-build                 Update OpenShift resources related to Jenkins images.
  apply-jenkins-deploy                Install a jenkins instance in the ods namespace (needed by the provisioning app)
  start-jenkins-build                 Start build of all Jenkins BuildConfig resources.
  start-jenkins-build-master          Start build of BuildConfig "jenkins-master".
  start-jenkins-build-agent-base      Start build of BuildConfig "jenkins-agent-base".
  start-jenkins-build-webhook-proxy   Start build of BuildConfig "jenkins-webhook-proxy".

  install-provisioning-app            Install the provisioning app.
  apply-provisioning-app-build        Update OpenShift resources related to the Provisioning App image.
  start-provisioning-app-build        Start build of BuildConfig "ods-provisioning-app".
  apply-provisioning-app-deploy       Update OpenShift resources related to the Provisioning App service.

  install-doc-gen                     Install the documentation generation image.
  apply-doc-gen-build                 Update OpenShift resources related to the Document Generation image.
  start-doc-gen-build                 Start build of BuildConfig "ods-doc-gen-svc".

  install-sonarqube                   Install or update SonarQube.
  apply-sonarqube-build               Update OpenShift resources related to the SonarQube image.
  start-sonarqube-build               Start build of BuildConfig "sonarqube".
  apply-sonarqube-deploy              Update OpenShift resources related to the SonarQube service.
  configure-sonarqube                 Configure SonarQube service.

  install-nexus                       Install or update Nexus.
  apply-nexus                         Update OpenShift resources related to the Nexus service.
  configure-nexus                     Configure Nexus service.

  backup                              Create a backup of the current state.
  backup-ocp-config                   Create a backup of OpenShift resources in "cd" namespace.
  backup-sonarqube                    Create a backup of the SonarQube database in the current directory.