The HTML5 Ant Build Script seems to be primarily a front end tool - https://github.com/h5bp/ant-build-script
But does anyone know if it's possible to run the build script on a server? Reason for this is that there are three of us on our team and it makes more sense for the script to be run automatically when someone has pushed to the server via git rather than all three of us running the script locally.
I may be a million miles off with this but is someone able to offer a good solution for us not having to run the script individually?
Related
I started to pick up Jenkins recently and want to see how it will fit my working environment. One of the very first tasks I want to do is to create a Jenkins project that will run a bash script located on a remote server via ssh, not copy a local script to a remote server then run it.
I could not find much helpful information online and pretty much have no idea where to start. I am pretty sure others may have the same questions, so thought to ask it here.
Thanks
CICD Process with Jenkins, Bitbucket, SSDT(SQL Server Data Tools).
Please list out the steps to perform CICD Process.
Including what plugins i need to install in Jenkins for SSDT(SSIS-ISPAC file) or SQL Database Solution(DAPAC file)
This question is very broad and as with all the stuff related to databases the best answer would be "it depends". As far as I know that there is no proper plugins either for Jenkins nor for Bitbucket that work with SSDT very well so you'll need to implement all your actions by yourself.
It will depend on your system how the pipeline should look like. There are a lot of questions that you'll need to answer first but without knowing your exact situation it is very hard to suggest you something specific. Example questions:
How many environments do you have?
Do you have tests?
Can somebody change the state of the destination database manually, passing the CI/CD pipeline?
Will you run publish on every commit?
Do you trust what SSDT will decide how to publish database? (Mostly people would like to preview the script that would be executed on prod)
Then after answering these questions you'll might know what will you need. After that you need prepare the proper publish script, exclude/ignore/add object types you'd like to deploy and use MSBuild.exe and SQLPackage.exe command line utilities. You'll run these utilities with specific set of arguments and paths to the publish configs, DACPACs, etc. Bamboo and Jenkins supports command line commands for that.
I am using Vagrant to provide a 'synchronised' and standardised development/test/uat/staging and production environments.
I am now looking at how to standardise my CI build process. I like the look of Jenkins but I am confused as to what the best way to deploy it is. Should I have it deployed in a stand-alone CI box or install it on all the various environments?
I guess I am a little confused here. Any help much appreciated, Thanks
The standard approach is a stand-alone CI server shared by the development team. This common server (at a well known URL) provides the development dashboard for a team and the only authorized way to publish into the release repository (Developers not allowed to publish directly)
You could go for extra credit and also setup an instance of Sonar which in my opinion is much better suited as a development dashboard, providing a richer set of metrics and also serves as a historicial record for development.
Finally Jenkins is so simple to setup, there is nothing stopping developers from running their own instances. I find that with Sonar it matters less and less where a build is actually run, once the release credentials are properly controlled. In fact this attitude is important as it prevents the build server from turning into a delicate snowflake :-)
Update
There's a vagrant plugin for Jenkins which might prove useful in running your current processes.
You're likely better off running Jenkins as a shared stand-alone server.
However, I highly recommend that you set up your builds in such a way that they can be run on each developer's machine locally as well. This is particularly key with unit-tests.
In our setup, we have a shared Jenkins server that executes all of our builds using NAnt. Each developer also has NAnt installed and can run the build and unit-test portions of the build freely. Ideally integration tests could also be run, but we're not quite there yet and having them execute on the CI server still gives us that proper feedback even if it takes a little longer to get.
I work in a team which maintains a Java website and back end java jobs and shell script jobs.
After all developers complete their updates, only the relevant ones are committed to source control system.
Later ant build scripts are run and war files are generated.
Along with these war files there will genrally be shell scripts etc to be copied to QA/PROD.
Then one fine day there is a team call the release management team which will transfer the code from our Dev environment to QA/PROD.
Recently I came across the Continuous Integration systems like Jenkins/Hudson.
Can these tools build all the changes committed and automatically transfer my code to QA/PROD.
BTW I work in a AIX Server environment and use Tomcat as the Container.
I am more curious whether the tool will be able to copy my code to QA/PROD.
Please Clarify.
The answer is almost certainly yes, depending on your particular setup for copying the code. There is a large number of plugins for this purposes at the appropriate Jenkins wiki page. You should be able to find something there for your needs.
I have build scripts that builds, test, version and packages my projects as artifacts to a staging area for each of our environments ready for a versioned release to a given environment (and labels the changeset).
I want to stop doing this automatically and only deploy on demand.
My problem is I am using TFS and the friction is just immense.
I basically want to have an easy way to
Get a specific version from source control
build it for a specific enviroment -DONE
deploy it. -DONE
The last 2 steps are trival. The "getting by label" it not that much fun with TFS.
Any ideas/pointers other than use stop using TFS?
just ask on twitter next time :-)
Seriously though, have a look at TFS Deployer on codeplex. The way it works is that you do a normal build with versioning of the output like you normally would, but you pull out all the deployment stuff from it.
Next, setup TFS Deployer - it listens for changes in the Build Quality and the fires off a powershell script that you write that does all the deployment work. For example, when you change the quality of a build to something like "deploy to UAT" it can fire off a powershell script that then does whatever you need it to. To do a deploy you just go to build explorer, set the quality to whatever you want and let powershell do the rest - you'll get an email of the results as well so you know if it works or fails.
Go have a look at it and if you get stuck just ping me and I'll help you out.