Gradle Training | Gradle Course | Online | Classroom | India | USA | UK

gradle-training

Gradle is the next generation in build automation. It uses convention-over-configuration to provide good defaults, but is also flexible enough to be usable in every situation you encounter in daily development. Build logic is described with a powerful DSL and empowers developers to create reusable and maintainable build logic.

End of this training, you can empower yourself to automate your build

  • Learn the best of Gradle
  • Work easily with multi-projects
  • Apply Gradle to your Java, Scala and Groovy project

Contact us at info@scmGalaxy.com

Table of Contents

Agenda 1: Getting Started
Introduction
Prerequisites
GVM to Manage Gradle Versions
Manual Installation in Windows/Mac/Linux
Installation Troubleshooting
Gradle Installation Binaries
Default Project Layout
Gradle Wrapper
Conclusion
Agenda 2: Gradle Tasks
Introduction
build.gradle
A Taste of Groovy
Dynamic Tasks
Gradle Tasks API
Using Ant Tasks
Using DAG
Agenda 3: Java, Groovy, and WAR Plugins
Introduction
Java Plugin Tasks
Hooking into Maven
Testing
Multimodule Java Projects
Creating a Distribution
Groovy Plugin Tasks
Building a WAR
Conclusion
Agenda 4: IDE Integration
Introduction
IntelliJ
Eclipse
NetBeans
Conclusion
Agenda 5: Dependency Management
Introduction
Dependency Types
Declaring Dependencies
External Dependencies
Publishing Artifacts
Dependency Configurations
Conclusion
Agenda 6: C++ Support
Introduction
Supported Platforms
Plugins
Libraries
Executables
Tasks
Configuring on Linux/OSX/Windows
External Dependencies
Project Dependencies
Publishing
Native Support for Variants
Agenda 7: Building JavaScript (gradle-js-plugin)
Introduction
Specifying Your Sources
Combining Your Sources
JSHint
JSDoc
Props2JS
RequireJS
Gradle CSS Plugin
Conclusion
Agenda 8: Building Scala
Introduction
Usage and Tasks
Project Layout
Compiler Setup/Incremental Compilation/Forked Execution
Dependencies
Fast Compiler Support
Conclusion
Agenda 9: Continuous Integration Servers
What Is Continuous Integration?
The Jenkins/Hudson Plugin
TeamCity
Bamboo
Conclusion
Agenda 10: Repository Managers
What Is Repository Management?
Artifactory
Bintray
Nexus
Conclusion

About us:
scmGalaxy online platform is a community initiatives based on Software configuration management and DevOps that helps members and organizations to optimize their software development process, advocating agile methodologies and improve productivity across all aspects of Application lifecycle management. We provide consulting, training and mentoring services in agile development practices such as Source Code Management, Continuous Integration, Build management, Test-Driven development, Acceptance-Test driven development, Build automation, code quality practices and automated testing and continuous delivery.

We provide job oriented training in the area of Software Configuration management, Build and Release Engineering and DevOps domain . Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. This course offered online around the globe which include India, USA, Europe, Australia, Bangalore, Delhi, Pune, Mumbai, Chennai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering and DevOps with more than 10 years industry experience in India.

Contact us

Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with automated course within your premises.
Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-line course. Please contact us for more details.
Audience
This is a hands-on, practical course designed to teach specialized skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer, DevOps engineer and developer and QA audience.
Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.
Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.
Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.
Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.
Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us. Please email us at info@scmGalaxy.com

Gradle Training in India,

Gradle Training in California,

Gradle Training in Australia,

Gradle Training in Bangalore,

Gradle Trainer,

Gradle Training in Europe,

Gradle Training in USA,

Gradle Training in Hydrabad

Tagged : / / / / / / / / / / / / / / / / / / / /

Going meta with Meta-Runners in TeamCity

teamcity-meta-with-meta-runners

Going meta with Meta-Runners in TeamCity

Official Reference – https://confluence.jetbrains.com/display/TCD9/Working+with+Meta-Runner

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.

Note

While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku git@heroku.com:django-ci-example.git  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.

Note

Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (https://github.com/moredip/heroku-headless).

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

Going meta with Meta-Runners

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.

Tip

A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

Going meta with Meta-Runners

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.

Tip

We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Using Meta-Runners

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Using Meta-Runners

Tip

It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.

Note

Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted i

Tagged : / / / / / /

Build Configuration Templates in Teamcity | Teamcity Guide

build-configuration-templates-in-teamcity

Going meta with Meta-Runners in TeamCity

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.

Note

While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku git@heroku.com:django-ci-example.git  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.

Note

Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (https://github.com/moredip/heroku-headless).

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

Going meta with Meta-Runners

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.

Tip

A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

Going meta with Meta-Runners

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.

Tip

We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Using Meta-Runners

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Using Meta-Runners

Tip

It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.

Note

Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted into Meta-Runners.

Reference Book – Learning Continuous Integration with TeamCity by Learning Continuous Integration with TeamCity

Tagged : / / / / / / / / /

Integrating Github With Eclipse | Github Integration With Eclipse

github-intergration-with-eclipse

Tagged : / / / / / / / / / / / / / /

Puppet Training for Devops and System Administrators | Puppet Course

puppet-training-for-devops-and-system-administrators

Puppet Training for DevOps and System Administrators

Agenda –

  • Introduction to Puppet
  • Installing and Configuring the Puppet Master
  • Installing and Configuring the Puppet Agent
  • Creating Manifests
  • Creating and Using Modules
  • Creating File Templates
  • Configuring Hiera
  • Windows Configuration Management
  • Version Control

Contact Info

  • Email – info@scmgalaxy.com
  • Call:- +91 700 483 5930
  • Skype – scmGalaxy

Training – http://bit.ly/scmgalaxy-training

Calender – http://bit.ly/scmgalaxy-calender

Location – Bangalore, Hydrabad, Pune, Mumbai, Delhi, USA, Australia, Canada

The Basics

  • Introduction To Configuration Management
  • About The Author
  • Why Puppet?
  • How To Access Your Working Files

The Puppet Infrastructure

  • uppet Agents
  • Puppet Masters
  • MCollective And Systems Orchestration
  • Cross Platform Puppet

The Puppet Run Cycle

  • Introduction To Puppet Run Cycle
  • Gathering System Facts
  • Node Matching And Catalogue Compilation

The Puppet Language – A Basic Primer

  • Puppet Resources – How To Define System Resources
  • Applying A Simple Puppet Manifest
  • Puppet Types
  • The Package File Service Patter
  • Applying Conditional Logic In Puppe
  • Fact Conditionals – Choosing A Course Of Action

Organizing A Puppet Environment

  • Defining Nodes
  • Puppet Modules – Reusable Code
  • Forge Modules – Where To Find Reusable Code
  • Provisioning A Web Server
  • Class Parameters – Applying Variables
  • Hiera Parameters – Defining Variables
  • Executing Modules Against A Puppet Master With An Agent
  • Reporting With Puppet

MCollective

  • MCollective And Live Management
  • MCollective With Puppet
  • Using MCollective To Interact With Services
  • Using MCollective To Interact With Puppet

Additional Tools

  • Managing Modules With Librarian-Puppet
  • Managing Directory Environments And Modules With R10K
  • External Node Classifiers And Reporting With Puppet Dashboard – Part 1
  • External Node Classifiers And Reporting With Puppet Dashboard – Part 2

Conclusion

  • Wrap-Up And Further Resources

About us:
scmGalaxy online platform is a community initiatives based on Software configuration management and DevOps that helps members and organizations to optimize their software development process, advocating agile methodologies and improve productivity across all aspects of Application lifecycle management. We provide consulting, training and mentoring services in agile development practices such as Source Code Management, Continuous Integration, Build management, Test-Driven development, Acceptance-Test driven development, Build automation, code quality practices and automated testing and continuous delivery.

We provide job oriented training in the area of Software Configuration management, Build and Release Engineering and DevOps domain . Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. This course offered online around the globe which include India, USA, Europe, Australia, Bangalore, Delhi, Pune, Mumbai, Chennai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering and DevOps with more than 10 years industry experience in India.

Contact us at info@scmGalaxy.com

Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with automated course within your premises.
Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-line course. Please contact us for more details.
Audience
This is a hands-on, practical course designed to teach specialized skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer, DevOps engineer and developer and QA audience.
Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.
Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.
Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.
Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.
Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us.

Please email us at info@scmGalaxy.com

  • Call:- +91 700 483 5930
  • Skype – scmGalaxy

Tagged : / / / / / / / / / / / / / / / / / / / / / / /

Build and Release Course Training with Jenkins / Maven /Ant/ SVN & Git

build-and-release-training-with-jenkins-maven-ant-svn-git

Upcoming Training Dates | Training Agenda | Training Calender | FAQ | Why scmGalaxy Online Training

Click Here

Mode – Online based
Email – info@scmgalaxy.com

Lab Setup Details – Prerequisites
Operating Systems – Windows 7 or Linux(RHEL 7.X or Ubantu)
JDK 1.7 or Higher
SCM Tool Clients Installed (SVN, GIT, Perforce)
Servlet container like GlassFish and Tomcat (If one wants to host Jenkins outside) – Optional

[If trainee is having any specific learning agenda to be addressed in this training apart from the table of Content as below; please email me @ info@scmgalaxy.com]

Table of Content

Continuous Integration with Jenkins

  • What is Software Configuration Management
  • What is Build and Release Engineering
  • Introduction of Version Control Management?
    • Basic usage of Subversion
    • Basic usage of git
  • Introduction of Build Management?
    • How to write ant script?
    • How to write Maven script?
    • How to write MSBuild Script?
  • Introduction of Release Management?
  • Benefit of Continuous Integration?
  • Different Continuous Integration Tools?
  • Focus on Jenkins
  • Installation and Setup of Jenkinks
  • Configure a Job to Build the Project using SVN /GIT and ANT/Maven
  • Using Build Script (Ant, Maven and MSBuild) with Jenkins
  • Authentication and Authorization in Jenkins
  • Lab and Assignment
  • Nodes Setup in Jenkins
  • Labels, Tags and Notification using Jenkins
  • Empowered with Plugins in Jenkins
  • 20 Popular Plugins and Their Usage
  • Integrating Jenkins with Junit for automated testing
  • Integrating Jenkins with HP-QC for automated testing
  • Integrating Jenkins with Cobertura for test Coverage
  • Integrating Jenkins with Sonar for static code analysis
  • Release and Deployments using Jenkins and Nexus
  • Advance Jenkins
    • Jenkins Scripting
    • Jenkins Command line
  • Reporting and Dashboard using Jenkins
  • Lab and Assignment

Build and Release Training In Bangalore | Build and Release Training in India | Build and Release Training in Hyderabad | Build and Release Training in Delhi | Build and Release Training in Pune | Build and Release Trainer In Bangalore | Build and Release Trainer in India | Build and Release Trainer in Hyderabad | Build and Release Trainer in Delhi | Build and Release Trainer in Pune

Tagged : / / / / / / / / / / / / / / / / / / / / / / / /

If a linux-build-server suddenly starts getting slow, what would you check?

linux-build-server

If a linux-build-server suddenly starts getting slow, I would divide my approach / troubleshooting into 3 section as follows;

1. System Level troubleshooting

a. RAM related issues

b. Disk Space related Issues

c. Disk I/O read write issues

d. Network Hardware issues

e. Mount issues

f. Too Many process running in the machine

2. Application Level troubleshooting

a. Application is not behaving properly. Hit to Application log file OR application server log file OR web server Log file and try to understand the issues.

b. zombie process issues – Find out if any as such process which is causing the system performance issues.

c. Application Log – depends on the application installed, this can be referred and make use of the experience with the project and troubleshoot.

d. Web Server Log – we can check http, tomcat log as well.

e. Application Server Log – We can see jboss, weblogic logs to see if the application server response/receive time is the issues for slowness.

f. Memory Leak of any application – This is one of well known issues in lunux based server due to bad application coding. Many times this can be resolved either by fixing the code or rebooting. But many other solutions are there to apply.

3. Dependent Services troubleshooting

a. SMTP Response time – SMTP server is not responding faster which is causing delay in response and queue up many processes.

b. Network issues – There are many System performance issues is dependent on network or service which is depends on the network.

c. Firewall related issues

d. Antivirus related issues

 Some of the useful commands for troubleshooting are..

1. df –k

2. du –sh

3. top

4. uptime

5. ps –eaf | grep

6. vmstat

7. ping

8. tail –f <logfile>

9. iostat

10.free

11.kill -9

12.mount

13.sar

14.ifconfig eth0 | enable | disable

15.traceroute

16.netstat -r

17.nslookup

18.route

   There are various options available for each commands and depends on the need during the troubleshooting, right commands can be applied. To find arguments and their explanation, I usually refer google.com rather than man page.

Tagged : / / / / / / / / / / / / / / / / /