Day: February 24, 2015

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

by scmgalaxy KTrainingLeave a Comment on 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

by scmgalaxy KTeamCityLeave a Comment on 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

by scmgalaxy KBuild Management & ToolsLeave a Comment on 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

by scmgalaxy KRepository Manager ToolsLeave a Comment on Integrating Github With Eclipse | Github Integration With Eclipse

github-intergration-with-eclipse

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