One time we used Oracle Golden Gate to sync Oracle databases from active to passive.
So that it is easy to flip if there are any issues.
Dependencies’ version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:
1.0: “Soft” requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
[1.0]: “Hard” requirement on 1.0
(,1.0]: x <= 1.0
[1.2,1.3]: 1.2 <= x <= 1.3
[1.0,2.0): 1.0 <= x = 1.5
(,1.0],[1.2,): x = 1.2; multiple sets are comma-separated
(,1.1),(1.1,): this excludes 1.1 (for example if it is known not to work in combination with this library)
Notes: This notation is good for products.
Not good for service projects. We need to have tight grip on versions, which are going into production from time to time.
Problem: Many are pointing public repos. This is not good practice.
Setup JFrog QA and Prod repos in organization.
JFrog QA pulls files from public repos on demand basis or periodic basis.
Builds will be tested and make sure that there are no corrupted jars and all are having proper required license.
Developers can point JFrog QA repo.
When build need to happen in Junkins/Hudson…it uses JFrog Prod.
Developers need to inform admins about required files.
Admins assure integrity of required jars to push to JFrog prod.
Also they will validated required licensing issues for given jars.
This is more safest and controlled way to control final artifacts which are going into production.
Gradle is an open source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration. Gradle uses a directed acyclic graph (“DAG”) to determine the order in which tasks can be run.
Gradle was designed for multi-project builds which can grow to be quite large, and supports incremental builds by intelligently determining which parts of the build tree are up-to-date, so that any task dependent upon those parts will not need to be re-executed.
The initial plugins are primarily focused around Java, Groovy and Scala development and deployment, but more languages and project workflows are on the roadmap.
Directed acyclic graph: https://en.wikipedia.org/wiki/Directed_acyclic_graph
Domain-specific language: https://en.wikipedia.org/wiki/Domain-specific_language
Spring Boot with Gradle: https://spring.io/guides/gs/spring-boot/
1. Time to move to Gradle instead of Maven for new projects. In Maven we need to write plugins. Here easy to code directly, because it is Groovy Language.
2. Advanced features
3. Support for Java/Scala/Groovy combinational projects (Didn’t checked Maven)
1. Too much customization kills over a period of time.
2. Gradle is selling tutorials and Enterprise version. We may end up with payments in case of complex issues.
3. Better not to deviate from standard Java folder structures
Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute withOracle.
Important features for large Projects
Setting up Master / Slave:
Many of us think that Jenkins is only for Build. But it can do anything by triggering scripts with parameters.
Build With Parameters Plugin:
This type of customization gives control to Engineering teams / QA teams to build and deploy on demand basis without any support from deployment team.
How Jenkins Builds the Netflix Global Streaming
Self service build and deployment at Netflix (Agile 2013)
Conclusion: Jenkins is good free knife. After utilizing all its plugins to their maximum potential, we can see that Jenkins is a Swiss Knife.
Other tools licenses are costly and Jenkins will live long with open source contributions.
Atlassian’s Product and comes with easy integration with Atlassian’s products.
This is costly for open source / community projects.
Junkins (Hudson): MIT License and came with many useful plugins.
I liked this plug in
From my experience Junkins is best.
List of Continuous Integration Software
Gradle is another Build System similar to Maven.
I didn’t like Gradle, because
1. Proprietary software build to get service agreements and make money.
2. Training is very costly.
3. Pushing away from structured development to unconventional development.
I always prefer Apache projects.
I may change my opinion down the line.
Deploying applications in more than one server is painful.
We need to define deployment strategy, Rollback strategy along with verification and validation process.
For each environment properties files / paths are different.
Many times Release Managers / Deployment Engineers solve this through shell/PERL Scripting and manual process with the help of runbooks.
These tools can help to reduce this manual work.
Salt – http://saltstack.com/ (*****)
Salt – http://docs.saltstack.com/topics/
Puppet – https://puppetlabs.com/
DeployIt – http://www.xebialabs.com/tour
At individual level
In Eclipse IDE use following files and share with team to maintain consistency.
TestNG Test Cases
Emma plug in to check code coverage
Tie the memory and performance numbers to test cases
At team level
What happens in Hudson?
Configure following in Hudson, so that it is easy to check after each build.
Code Coverage Report
Open Tasks Report
Surefire Test Report
At organizational level
How to compare different projects / modules in organization?
Use SONAR and use maven plug in to push the data to Sonar server.
Lines of Code