This presentation shows how to create a pipeline in Jenkins CI server for push button deployment. It demonstrates the different tools used for the same and also what are the advantages of having a build pipeline
I am Leena, working as Chief Consultant with ContinuousDelivery.in Push button deployment helps to have easy deployments and make the deployment fun.
Show it in action. Make sure that the following is mentioned: 1. Retry 2. The blue legent
A set of tools and its extensions which allows you to achieve this.
1. An open source continuous integration server. 2. Was known as Hudson 3. Its plugins are its assets, which allows eay integration with any other tool. 4. There are other tools for both CI and Deploy/release management, we chose Jenkins because it was easy to setup and it fits into our requirements.
Capistrano is a tool for deploying web applications. It can deploy code from your repository (SCM) to one, or more servers. Other tools which is built on top of it RailsMachine's Moonshine and Rubber using which you can extend it for configuration management. http://railsmachine.com/articles/2009/03/18/moonshine-what-burns-blue-makes-your-blues-go-away/ https://github.com/wr0ngway/rubber/wiki
What does this bring to the table. Lets see the advantages the approach has.
No more checklists, Don't need a human to follow a series of exactly same steps every time.
Clearly shows WIP, which tells you to push to production immediately or being proactive to let the client know about that.
Happy team members, they can see how the code gets transformed into working features which actual users will be using and also allows them to see the big picture.
Easy as simple as clicking of a button Easy to setup And once setup, low maintenance
Anyone can do it. No dependency on experts. Even client can can do it when they feel its ready
Aligns with the XP practices 1. small releases 2. If its good do it all the time 3. "Done Done"
It is not restricted to 3 steps. You can add these to the pipeline: 1. Acceptance tests 2. Code metrics 3. Test coverage 4. Non functional tests say security/performance etc. All of these steps need not be sequential. You can run them in parallel. Say for eg: 1. Run your performance/security tests in parallel 2. Run your code metrics tool parallel to test coverage
It is not restricted to 3 steps. You can add these to the pipeline: 1. Acceptance tests 2. Code metrics 3. Test coverage 4. Non functional tests say security/performance etc. All of these steps need not be sequential. You can run them in parallel. Say for eg: 1. Run your performance/security tests in parallel 2. Run your code metrics tool parallel to test coverage
It is not restricted to 3 steps. You can add these to the pipeline: 1. Acceptance tests 2. Code metrics 3. Test coverage 4. Non functional tests say security/performance etc. All of these steps need not be sequential. You can run them in parallel. Say for eg: 1. Run your performance/security tests in parallel 2. Run your code metrics tool parallel to test coverage
It is not restricted to 3 steps. You can add these to the pipeline: 1. Acceptance tests 2. Code metrics 3. Test coverage 4. Non functional tests say security/performance etc. All of these steps need not be sequential. You can run them in parallel. Say for eg: 1. Run your performance/security tests in parallel 2. Run your code metrics tool parallel to test coverage
It is not restricted to 3 steps. You can add these to the pipeline: 1. Acceptance tests 2. Code metrics 3. Test coverage 4. Non functional tests say security/performance etc. All of these steps need not be sequential. You can run them in parallel. Say for eg: 1. Run your performance/security tests in parallel 2. Run your code metrics tool parallel to test coverage