Thank you to everyone who joined us on our webinar, the recording is now available .
Below are some of the questions we received to webinar:
Q: If you use a VPN to access source code on premise from CloudBees DEV@cloud, would source code still be accessible by CloudBees employees?
A: CloudBees support engineers do have access to the Jenkins build to provide support, but that access is restricted. Some plugins might pull and cache source on the master, which you should also be aware of. You can also use on-premise executors from the cloud if needed, to mix the hosted builds with something you want to remain isolated on-prem. Finally, some customers use their own VPC as an IPSec-based bridge to our OpenVPN-based connection, providing further control over access.
Q: What is Puppet and Chef? Are they scripting languages or tools?
Q: Artifacts are stored in a repository. Is it a network share or some sort of repository? What was its name?
Q: Why would one choose Jenkins over Bamboo as the main ingredient of a CD solution?
Response: Bamboo is a very capable tool, but people choose Jenkins over it for many reasons. As one of the most active community-driven open source projects, Jenkins enjoys a momentum that is hard to beat. Jenkins is designed to be extensible via its plugin architecture. If you (and we) can't achieve what you want with a plugin, then something must be broken in Jenkins core! What this means is that if you need to connect Jenkins to some system you have in-house, then there is likely to be a solution in the +900 plugins already -- or you can build one yourself. This is also a reason Jenkins is popular not just with developers, but with Ops people. Bamboo is often used along with other Atlassian products, but Jenkins has great connectivity to JIRA, Bitbucket, Stash and Hipchat. CloudBees is committed to working closely with the Jenkins community to continually improve the open source offering, but we also provide Jenkins Enterprise by CloudBees and Jenkins Operations Center to add value and commercial support.
Q: While deploying Jenkins, how can you manage the script file to run after the build is prepared? I tried to do it but it runs just before the code from git is taken...
Response: We are not sure exactly what you are referring to. However, you can configure a "post build step " in a variety of ways within Jenkins to execute a script after a build. If you want to commit to master only when a build is successful, you can use the Validated Merge plugin that is part of Jenkins Enterprise. If neither of these suggestions is addressing your question, you can submit the question with some more specifics to StackOverflow using the Jenkins tag , where CloudBees and community members are very active.
Q: For an enterprise with virtual stack -- I know the Docker plugin exists now in Jenkins -- any case studies or mature examples on that being used for env provisioning as well as automated deployment promoting change from DEV through Prod incl env prop changes?
Response: Well, as Duncan mentioned, Netflix is always a great example , and Viridity's case study with its usage of microservices is quite consistent with Netflix's style. But not everyone can be Netflix! Here's a very nice Velocity conference presentation from Mandi Walls (@lnxchk) of Chef/OpsCode that will give you some specific examples of how to automate deployment using Jenkins in operations. This InfoQ article by Kohsuke and Andrew Phillips of Xebia also provides some specifics about constructing a CD pipeline with Jenkins.
Q: What's the best source for learning Jenkins and all these processes in detail?
Response: Unfortunately, I don't think there is really a great cookbook our there -- yet. Jez Humble and Dave Farley's book is certainly the reference on Continuous Delivery. To get up to speed on Jenkins, there is John Smart's book and some more recent books. The Jenkins User Conferences are great places to hear real-world experience and to rub elbows with others in the very open and supportive community. For online reading, I mentioned one of my favorite bloggers Jeff Sussna . Other online forums that you might find useful (aside from the CloudBees developer blog ) are ContinuousDelivery.com and DevOpsGuys . DZone's recently published Guide to Continuous Delivery might also be of interest. As I mentioned in answer to a separate question, there is a very nice Velocity conference presentation from Mandi Walls (@lnxchk) of Chef/OpsCode that will give you some specific examples of how to automate deployment using Jenkins in operations. This InfoQ article by Kohsuke Kawaguchi (CloudBees CTO and Jenkins founder) and Andrew Phillips of XebiaLabs also provides some specifics about constructing a CD pipeline with Jenkins.
Q: Continuous delivery too can deploy automatically on what all flavors of operating systems like Windows, Linux, and iOS? Are there any technology constraints?
Response: Certainly deployment to all flavors of Linux is common, along with Windows. But people use deployment tools to all kinds of systems, from mainframes to web apps to embedded systems. Deployment to iOS and Android is an interesting case. CloudBees supports iOS/XCode builds as part of our hosted service. But what does "deployment automation" mean when your app is gated by an Apple or Google-controlled approval process? Ironically, it means you need to be even more thorough in keeping your software in a release-ready state, and very confident as you roll out updates! Waiting days to get a critical fix to your customers can be a business killer. CloudBees partners with some companies with best-of-breed mobile testing solutions, both in terms of actual "device cloud" hosting as well as test automation.
Q: What are the best practices to automate the UI-centric testing?
Response: We mentioned Selenium from Sauce Labs during the webinar, and it is something we use internally at CloudBees. In the mobile space, emulators are useful but only get you so far. SOASTA has a terrific tool called TouchTest that lets you record and replay complex automated tests on touch-based devices. Robotium is one we run across on Android.
Q: How does Jenkins differ from Go (CD tool by Thoughtworks)?
Response: Go was conceived of as a continuous delivery tool, whereas Jenkins started with continuous integration and has evolved to address continuous delivery as driven by real-world users and community. The open source community has a lot to do with the differences, and perhaps this is why Thoughtworks has recently open sourced Go. Jenkins is the hub of continuous delivery because it connects to everything and is extensible, whereas as a proprietary product prior to being open sourced, Go depended more on a single company's resources to reach the long tail of surrounding systems. Jenkins also shines in its ability to just fit in to existing toolchains and processes. This allows Jenkins to be a tool that helps incremental adoption of CI/CD processes without being overly opinionated and imposing changes and processes on teams that they don't feel they need or benefit from.
Q: Any plan to organize on how to achieve CD in CloudBees?
Response: We offer Jenkins training and partner with experts who can help make you successful in achieving continuous delivery. As Kurt Bittner pointed out, a lot of the challenge in achieving CD is around cultural and organizational issues, not toolchain choice. But, your toolchain choices can be key to helping make the changes.
-- Steven G. Harris
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.