Devoxx team used to host it's registration and call-for-paper applications on it's own hardware, and as I proposed to host it on CloudBees Platform as a Service, they were so enthusiastic I quickly understood being sysadmins on this infra to keep the apps up and running 24x7 isn't a fun job. They prefer to focus on making the conferences happen and be even better every year.
The interesting challenge is that those application haven't been designed to be hosted in the Cloud. They don't use a fully stateless web framework à la Play, They aren't split into small REST services invoked from a pure Angular javascript frontend, they are ... like 99,9% existing application, using common Java Frameworks.
Registration application was the simpler one to migrate. It's a very classic Servlet-based application, designed using Vaadin for web UI, and a Spring and MySQL backend. We just had to make some minor configuration changes so that the app can get a datasource injected by the platform, as well as SendGrid JavaMail session.
Most container require you to add a dedicated deployment descriptor to declare container resources (jboss-web.xml, weblogic-web.xml, etc). If you don’t want production information to be stored in SCM neither hard-wired within the artifact, you probably rely on an external properties file to be loaded by spring on startup, or comparable workaround.
CloudBees platform let you inject parameters and resources to an application, so that you can have the exact same binary WAR deployed on staging environment and then on production, with just the adequate Mysql DataSource bound and configuration parameters (secret credentials, ...) injected.
Thanks to this feature, the Devoxx team is able to have staging environment be an exact replica of production environment, just with less connected users :) Deployment process is also the exact same one, and is ran on every commit that successfully builds the WAR. With such an homogeneous infrastructure, they can be very confident when deploying to production.
Devoxx team quickly setup a continuous delivery pipeline. As they push code to bitbucket - they use Mercurial, sorry for that, read my previous post - Cloudbees DEV@Cloud Jenkins is building the app and automatically deploying to the staging environment.
As the Platform handles concurrent versions deployment, the service isn't interrupted as you deploy a new app, the "old" application remains active until the "new" one is ready to handle requests, and then http traffic routing is switched. So, deployment to production isn't a stress anymore, with twitter announcement about temporary service black-out.
After some more testing, they can promote the build to production. A single click to deploy app in production, cool isn't it ?
This encourages rapid feedback, small change-sets between "releases", so small risks ... I won't explain you here what agile software development is !
Devoxx team also wanted to test the scalability of the platform, and then hit an issue as vaadin is using HTTP session to store UI state, so you can't use round-robin load balancer. Hopefully, cloudbees platform can be configured to enable sticky session. This is something you have to consider to host your application on a Cloud platform, as most frameworks rely on this feature, and sometimes you even don't know (I think about you spring-security!). The other option is to enable session clustering around the nodes your application is running on.
The Call For Paper application required more changes to be "cloud-compliant". This application let speakers upload existing slide decks so the CFP team can review a proposal from existing content. The application used to store those files on file system, using a parameter to configure the local directory. How does this translate when running in the Cloud ? The app is running on multiple clustered nodes. It starts on fresh new nodes every time a new version is deployed. So, even local file-system can be used for temporary files during request processing, it is not persistent, neither replicated.
This is something CloudBees plan to address in 2013, but at this time there was no other option than changing the application code to use Amazon S3 to store files. JClouds API and S3 provider helped a lot to reduce the amount of time spent to fix this design issue, and the application was running on the staging environment after a few hours of coding.
The RUN@Cloud console gives general health and performance information about the applications, so the Team can monitor his application and - if necessary - change the platform configuration to use larger nodes, more nodes, or both. They also enabled NewRelic add-on to get fine grained analysis, that could help in case something wrong happes.
7 commentaires:
Hi
Thx for the post. I have set up my own continuous delivery on Cloudbees but think it is not perfect so i would like to see how other authorities have it set up. Cloudbees docs are becoming better each month but I still miss some "best practices" or "full pipeline" (including deployment to staging, testing via SauceLabs Selenium) examples. It is not only about technicals (Dev/Run@Cloud configuration) but also about organization of builds, their dependencies, job triggers and other other stuff.
Regarding Devoxx jenkins continous delivery, could you answer me a couple of questions:
- does Devoxx team have a single job for particular application (excluding jobs created for sonar)?
- Does a single application job compiles, unit tests, and deploys to staging env, whereby promoting a given build will result in deployment to production (via "deploy to cloudbees" promoting action)?
- does jenkins job always checkout from particular mercurial branch?
- what were the steps when deploying to staging/prod for the first time. Was it sth like:
create staging/prod db, create staging/prod app, bind staging db to staging app, bind prod db to prod app, define some extra configuration parameters for each app, run jenkins job to deploy to staging for the first time? Or do they use cloudbees-web.xml?
- i do not get what you mean by:
"As the Platform handles concurrent versions deployment" - can you point me to any cloudbees doc that describe "http traffic switching" just after a new deployment too place?
There is many ways to implement a continuous delivery pipeline, no silver bullet solution. Some like to promote binaries, some like to use git branches, some like full automation, some like manual promotion steps ...
to answer your questions :
- Devoxx team uses a single job, with promotion to deploy to production. For more complex builds it would make sense to split into a chain of jobs
- Mercurial plugin is monitoring all branches. Anyway they don't use branches a lot. Team to use topic-branches and integration branches may restrict continuous-delivery job accordingly
- We used configuration parameters and resource binding, set from SDK on first deployment, not cloudbees-web.xml that is (imho) the "legacy" way to configure an app.
- I don't think we have doc on concurrent version deployment. The main idea is that your app isn't stopped as you deploy a new version. It keep on serving http request until the new deployment is ready, and then http traffic is routed to the new instance to ensure continuous service.
Thx for the answers.
Really helpful.
Regarding implementation of continous delivery i would like to see one day a series of articles/blog posts on cloudbees describing different options/approaches in a manual/half-manual/full automated environments.
Don't you mind the last 2 questions:
- What do you mean by "Team to use topic-branches and integration branches may restrict continuous-delivery job accordingly" ? Does it mean that topic/feature branches are not delivered to staging/prod env at all?
- does concurrent version control is provided out of the box for run@cloud in each case/subscription level? even if i do not use cloudbees loadbalancer or deploy to cloudbees domain ,i.e. http://..cloudbees.net ?
topic-branches won't go to production, they need to be merged in master (or "production") integration branch.
concurrent version deployment is the default one for all subscriptions.
great thx. Really appreciate your help.
We at DumpsCompany provide 24/7 support service for CloudBees Jenkins Engineer CCJE exam dumps. If you face any difficulty using our test engine or pdf file or any issue regarding questions answers, you can easily connect with us through live chat or email us on our support. We assure you that your problems will be resolved in a short period. Our expert team handles all of our customer's queries, so the chances are high of resolving your problem quickly.
Bundle package for CloudBees Certified CloudBees Jenkins Engineer CCJE
Our CloudBees Jenkins Engineer CCJE bundle package is the most attractive discount package we offer. We offer many discount packages, but this one is the best so far. Our bundle package for CloudBees Certified CloudBees Jenkins Engineer CCJE includes an online test engine and pdf files both. If you prepare from these two, you will see a major difference in your preparation level. Our customers using bundle packages are very impressed with our service. Your confidence will boost up once you prepare from both online test engine and pdf files.
Devoxx-on-CloudBees" is a transformative amalgamation of two powerhouse platforms, catering to the dynamic needs of developers and tech enthusiasts. This collaborative venture combines the excellence of Devoxx's renowned tech conferences with CloudBees' cutting-edge solutions in software delivery and automation. The result is an unparalleled hub for innovation, learning, and networking, offering a blend of insightful talks, hands-on workshops, and demonstrations. The synergy between these industry giants fosters an environment where participants can explore the latest trends, dive into practical applications, and connect with like-minded professionals. With its focus on empowering developers and businesses through knowledge sharing and technological advancements, "Devoxx-on-CloudBees" stands as a pinnacle event, driving the evolution of software development and engineering forward.
personal injury lawyer virginia
Estate Litigation Lawyer
Enregistrer un commentaire