For the deployment stages of our pipeline we needed to read the ecosystem.json file in order to find and use the environment specific properties for our deployment stages. Our application included an ecosystem.json file ( PM2-Deployment) which defined environment-specific properties (DEV, QA, UAT, PROD) for our application. We were also using Jenkins to automate scripts to deploy the application to an environment. ![]() In our project we were building Node.js applications. Rather than repeating code patterns in multiple locations (does not comply with principle of DRY), take things a step further and define that code pattern as a specific helper function that is managed and maintained in one global location. As we continually copy code for new jobs, we start to notice that we’re reusing the same code over and over again in many jobs. Rather, we look for an existing job with flows similar to what we need in a new job, we copy that code and modify it accordingly. As usage maturity grows, at some point we mostly stop coding pipeline jobs from scratch. As the number of Jenkins pipelines grow within your organization you’ll probably notice some repeating job patterns. Jenkins has also made it possible to build your own helper functions through the use of Shared Libraries. If for whatever reason the Nexus URL needs to change, or our service account needs to change, we can update these properties in one place to take effect in all jobs. Thus we only need to specify the NexusURL and credentialsID parameters one single time within global properties for all jobs to use. We use this exact stage block in all of our pipeline jobs to upload any built package to Nexus. The other variables (NEXUS_ARTIFACTID, ARTIFACT_FILENAME, etc.) are defined at the job level as these need to be changed for each job. In the example pipeline stage code above, NEXUS_SERVER (line 21) and NEXUS_CREDSID (line 19) are global properties defined within the Jenkins Master (the value of NEXUS_CREDSID is actually the identifier of a Jenkins credential). The great thing about pipeline code is that global properties and local variables are used in the same fashion. Also, if they were to change, we would prefer to make the update only in one place. We definitely don’t want to have to specify the Nexus Repo URL and login credentials (we use a service account for all uploads) in every pipeline job as those parameters should never really change. Instead you need to explicitly provide the Nexus repository URL, protocol and credentials within the pipeline stage block. This plugin was easy to use, however, it cannot refer to the Nexus login information as specified in Jenkins->Manage Jenkins->Configure System. The current Sonatype plugin does not support Nexus 3, so we used the Nexus Artifact Uploader Jenkins plugin. In the case of a recent project, we used Sonatype Nexus Repository v3 to store all of our packages built by Jenkins. These simple string name/value pairs can help a great deal with reuse and maintainability. These global properties can be used by every Jenkins job that is tied to a particular master. They are installed by the Global Variable String Parameter Plugin. Global properties can be found at Jenkins->Manage Jenkins->Configure System under the Global properties section. In this blog, we’ll give an explanation and a few examples of these features. There are a few mechanisms within Jenkins that we’ll call more intermediate or advanced features, but are relatively simple to implement, i.e. For anyone who has been responsible for maintaining source code of any scale, the source code 101 tactic of good source code maintainability is the implementation of consistency and reuse. Or imagine one or two people who have to maintain many different Jenkins pipeline jobs within a Jenkins Master. ![]() Imagine a large organization with many teams and Jenkins pipeline jobs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |