DevOpsQA NJ just held our November Meetup on Jenkins Workflow with Kishore Bhatia and Isaac Cohen from CloudBees as speakers. The venue was provided by ROKITT at a state-of-the-art office space with breathtaking views of NYC. Even though it was heavily raining outside, there was a great turnout of veteran and new members.
We kicked off with a fun speed networking over pizza and drinks provided by TEKSystems. Following that, I did an introductory session on Transformation thru Automation via Jenkins talking about 10 steps to get a head start on continuous integration and deployment. The steps include Identifying Bottlenecks, setting up a common repository, automating of the build, unit testing, environment configuration, test data management, regression testing and reporting.
Next, Kishore and Isaac gave an introduction to Jenkins Workflow followed by a detailed demo.
Kishore started off with a famous saying by Marc Andreessen, co-founder of Netscape – “Software is eating the world”. More and more things are getting automated and every business is becoming a software business. We are automating Ops so that we can do more Ops and automating Manual QA so that we can do real (valuable) Manual QA (e.g. exploratory testing).
Jenkins is the tool that orchestrates all the SDLC steps from code commit to binary delivery. There are currently 1183 plugins for Jenkins with new one developed every week. With today’s plugins, you
have to create atomic jobs that then call each other, which ends up hard to visualize how the ensemble works, especially when you have a lot of different projects.
Workflow was designed to automate and scale pipeline steps and tools and solve common pipeline problems such as Parallelism, Branching, Looping, Restarts, Checkpoints, Manual Input, etc. Jenkins Workflow is mostly open source with some advance features offered via enterprise edition by CloudBees. Workflows can be defined in one concise script, with a groovy-based DSL and 15 simple keywords.
Isaac took over to give the Workflow Demo. He explained that stages will be the different steps of the pipeline. The workflow script doesn’t have to be written directly in the jenkins job, but as an external file in your source code repository. New DSL can be c
reated to abstract the individual actions like source code checkout, build, test, etc. It will be possible to share this DSL in your jenkins and with the world, as well as download and use other people’s DSLs to leverage their code and avoid writing it yourself. Checkpoints can be combined with notification methods like email to get the input directly from the notified person. The multibranch Workflow system will support branching, any new branch in git will create a new workflow in Jenkins. Jenkins will scan all the GitHub repositories and add all the projects with Jenkins files automatically, as well as scan new projects and add them automatically in Jenkins.
At the end of the session, Kishore and Isaac gave us a glimpse of Jenkins 2.0 release which includes focus on Continuous Delivery use cases and UI/UX improvements.
If you would like to learn more about Jenkins Workflow, you can reach Kishore at [email protected] or Isaac at [email protected] . For more information about CI/CD transformation you can reach me at [email protected]
At the end we had a great Q&A session and a very warm open discussion. Looking forward to our next session.