In our Client project we have 6 applications , Three Java and three .NET.
We have the code in the same repository in different folders for each app.
The case is that we need to compare the artifacts which is being built with the previous builds to know changes are made or not.
If changes are made then deploy it
else
Do not deploy it.
Also, based on the apps. Say if I work on the One Java and one .NET app, I will want to deploy only these two and rest four apps need not be deployed unnecessarily.
How can we achieve this without manual intervention?
Please suggest us with a solution.
You can try to set up a build pipeline and corresponding release pipeline for each app.
In the build pipeline for each app, you can use the 'Paths' key to specify the file paths that can trigger the build pipeline.
In the release pipeline for each app, you can try setting up a step to execute the API "Builds - Get Changes Between Builds" to get the changes between the current build and previous build. If no any change made between the two builds, skip the subsequent deployment step.
[UPDATE]
Is there any equivalent API which could provide the difference between two artifacts even if the build manually runs without any changes? So if we do not see any changes in result we could cancel the release pipeline.
To avoid deploying the artifacts that have the same source version, as I mentioned above, you can try using the API "Builds - Get Changes Between Builds". In Response body of this API, it will return the array list of commits between the two specified builds.
If have changes between the two builds, the value of "count" property is the number of the commits. And in the "value"property (array object), these commits will be listed.
If no any change between the two builds, the value of "count" is 0, and "value" is an empty array.
In your case, you just need to check whether the value of "count" is greater than 0. If greater than 0, start the deployment. If equal to 0, skip the deployment to avoid re-deployment.
Related
I am developing a web application to migrate images from CVS to Adobe CQ. There is a requirement to maintain versioning for the images in a database table. The flow is as follows:
Check Out files from CVS -- returns a list of all files checked out, but does not tell whether a file was updated or newly added to CVS! (Due to the files being binary file, it seems it is not able to detect updates and all files are treated as additions)
Check if this is application's first run, if yes, then treat all files as additions. If not, for every file, check database for presence of record corresponding to this file. If record present, treat as update, else insert
... Carry on with other operations
For every insert, add an entry in the database
I have to detect if the application is running for the first time, or has been run previously. This also needs to support future tasks such as resetting everything and starting the application from scratch.
What would be a good way to do this? The application is hosted in WebSphere in Linux. I have thought of two ways:
a. creating an entry in a file with a flag set to true, which I will have to reset to false after the first run - difficult for a user to reset later
b. creating a .firstrun or similar file in the app folder somewhere and check presence of this file to determine first run, easier to reset for any user
Which of this is a better way? Or is there any other way to do it better?
You mentioned database. Why not to store in db, in even more extended way: when what version, # of runs, etc.
Our build takes a long time, even when nothing has changed. When I run mvn appengine:set_default_version it does a full build, which takes a few minutes.
Is there an easier way to call set_default_version, bypassing the build?
As requested by #Alex :)
I do believe you could build a custom flow to just to call set version. But seems like a complete overkill.
Since you should be changing the default version every once in a while and not on every build (I hope), would't the UI on the cloud Console suffice? You just go to Compute > App Engine > versions and setup the default.
Be advised some people reported issues with the new UI where default version was not changed, so if that fails you might need to use the old app engine console.
We are planning to automate the build system using Hudson. We are new to Hudson or it would be better to say this way that we are new to build automation process. Our application is on Java platform and the database is on MS SQL. This (automation) milestone is break down into different goals. The first step which we have is to automate database changes (DDL/DML) and during updating database if anything goes wrong it should be able to roll back the changes and send an e-mail to a group to notify the failure (with reasons). Otherwise, if succeed then allow to move on to the next step which is make the build and deploy with LiveRebel.
I think we should have a centric mechanism on build failure on any instance if a build fail it should be able roll back changes what it would have had done. For instance, if database changes failed as I said it should notified and don't proceed further. And, if database succeed and build making process failed (e.g because of Unit Tests) it should be able to roll-back the database changes. If notification can have failure details (like exception details with person responsible for this) it would be very helpful to diagnose and inquire appropriately. How can (should) I do this?
We are also interested to use LiquidBase with Hudson.
I would like to ask for your opinion and suggestions how should I plan this and what should be a good way to achieve this.
First of all you shouldn't mix up building and deploying. The database update would be part of your deploy process, not of your build process. Even if using continuous integration this should be kept separate. This means you do your database changes after the project was build and all your JUnit tests were run. If it fails before that it shouldn't perform the changes, so there would be no need for rollback.
As for your actual problem: I don't know any plugin that does what you want to do. In Hudson/Jenkins you always have the possibility to execute a batch/shell script. Write a script that performs your changes. The build should fail if your script exits with an error return code.
For sending notifications on build failure there are various plugins, including E-Mail.
I program Java using Eclipse and SVN in my company and one of the commit rules it's that each commit have their own purpose, and it's always one.
Sometimes I can get some work done but can't publish it on the server until the end of the day (it will break the build) and then I have to do some other work (non related to the first) and commit it, but if I do that I'm commiting changes related to 2 tasks.
What I want here it's to have a way to say to Eclipse that I want to separate those changes and on both of the tasks I want to work with the trunk code. So, basically it's a branch, but that never existed, in order to let me make separate commits. I thought about having N eclipse workspaces working with the trunk code and use each onde for each change, but that seems overkilling.
Is it doable?
In Intellij you have changelists that you can commit separately. Maybe this question can help you further on your way: Changelists in subclipse
The only way I can think of doing it so that you can make two different sets of changes within a single file is to checkout a second working copy for the second tasks set of changes, and work on those independently. When either task is complete you can commit the changes made in that working copy, and update the other working copy before committing that once it builds.
I'm one of those guys who step through their code a lot during development. Beginning with version 1.6.4 of the GAE Java development server, the server has been instrumented with calls to a function named Runtime.checkRestricted. This causes two inconveniences when I step through my code:
Whenever I step into a function, the debugger goes into the function Runtime.checkRestricted (for which there is no source code) at least once, often multiple times.
Whenever I step over a function call which has a large call tree underneath, it takes a very long time for the debugger to come back. (That's always a problem in the Eclipse Java debugger, but now it's really bad.)
For me, all this causes a serious drain on productivity. Is there any way to disable this instrumentation, or at least to prevent the debugger from stepping into it? I am using Eclipse with the GAE plugin.
Add a step filter to filter out all step breakpoints you are not interested in. The Eclipse documention provides a guide how to set up step filter.
In your specific case, you will want to add a package filter for com.google.appengine.tools.development.* , as this package and its subpackages contain GAE's Runtime class and RuntimeHelper class. Finally, don't forget to activate the option "Use Step Filters" (Shift + F5).