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.
Related
I want to setup a CI and CD processes for a React App for the company I'm working for, the following technologies are used:
React for frontend
Flask for backend
Docker
GitHub for source control management
currently we are using a script to build the app and than deploy it manually to AWS S3 bucket, I've read some article and watched tutorials and almost all of them cover Java based project and use Maven as a build tool to package the project before deploying.
appreciate if you could help.
I agree that the question is a bit broad but here but generally speaking you should ave a different CI pipeline for your frontend and backend application.
The implications of this are many since this will allow you to:
To use different release cycles for your backend/frontend application
Reduced build time
You might however at some point run an integration step to make sure everything holds together. Generally speaking your pipeline should look like (this should run on every commit):
Also make sure you choose a CI/CD tool that doesn't get in your way and that's flexible enough (i.e: GitLab, Jenkins).
Build docker image
Linter (to ensure a minimum code formatting and quality)
Unit Testing
Code coverage (Code coverage perse it's a bit useless but combined with how it evolves and enforcing a minimum % might help with quality)
Functional testing (this makes more sense for your backend stack if it uses a database for instance ...)
If everything passes then push to DockerHub
Deploy the recently built image to the corresponding environment. Example merging to develop implies deployment to your staging environment
This is a not related to code fix, but a general approach for test automation.
I have a test automation written in javascript which runs perfectly on my machine as well as my local jenkins.
Now, i want to use my company's server(centOS) and jenkins so that it is accessible to everyone in my organization.
Issue: nodejs version in company's server need update to run my automation, but server team wont do it since they are not sure if any other functionality used be other teams may start to break because of the upgrade.
Have you faced this situation. Do you have different servers for core code and automation scripts. Please suggest.
This is a complex situation that really depends on many variables. I would recommend using an agent that contains the proper version of Nodejs. With this solution you can leave the current build server how it is but you can also use the exact version of node you need. This will require an extra server/VM with the Jenkins slave software but this will remove the need to change the master server.
The solution my company went with is using Jenkins 2.x with Declarative pipelines and ephemeral Docker containers for builds. This allows you to use any Docker image such as the official Node image. You can pin a version and build it with that. With this there is no need to worry about the version on the server. Jenkins Master doesn't even need to actually build.
I've just finished setting up my Jenkins server but there seems to be one glaring problem that I can't find an answer to.
Shouldn't the Jenkins environment be an exact clone of the production environment to make it effective? None of the tutorials i've read mention this fact at all. So how do people deal with this fact? especially if they are using a single Jenkins instance for multiple projects that may be running on different infrastructure?
I can imagine puppet or chef might help here but wouldn't you be constantly re-provisioning the jenkins server for different projects. sounds pretty dangerous to me.
The best solution to me seems to be to not run the test on the Jenkins server itself but to spin up a clone of the production environment and run the tests on that? But I can't find a single solitary tutorial on how this could be done on EC2 for example.
Sorry if this is a bit of a rambling question. So how does everyone else deal with ensuring an exact replica of the production environment for Jenkins to run tests on? This includes database migrations as well now that I think about it.
Thanks.
UPDATE:
A few of the answers given seem to concern compiled languages like java or objective-c. In those situations I can see the logic of having the tests be plaform agnostic. I should have been more specific and mentioned that I use Jenkins for LAMP stack testing. So in that situation the infrastructure is as much a component that needs testing as anything else.Seeing as having PHP5.3 on one machine is enough to break a project that requires PHP5.4 for example.
There is another approach you can consider.
With Vagrant, you can create completely virtual environment that simulates your production. This is especially useful, when you want to test many environments (production, single node env, different OS, different DB) but you don't have enough "bare metal" machines.
You define proper vagrant environment. Next in Jenkins test item you setup proper machines, and execute tests on created vagrant environment.
Jenkins also supports a Master/Slave system (see here for details).
The jenkins slave itself does not need much configuration and could run on your production system replica, as it also does not need much configuration it should not influence your production clone significantly.
Your master would then just delegate the jobs (like your acceptance tests) to your slave. In that way you could also setup different production environments (like different OS, different DBs etc.) by just setting up a Jenkins slave for every configuration you need.
You are probably using Jenkins to check the quality of your code, compile it, run unit tests, package it, deploy it and maybe run some integration tests.
Given the nature of all those tasks, it is probably best that your Jenkins environment is NOT like your production environment. For example, you don't want your production environment to have your compiler installed (for many reasons, security to name one).
So, Jenkins is a development environment, and the fact that is doesn't exactly match your production environment should not be a concern to you.
However, I understand that perhaps you want to deploy your packages to a production-like or even production-clone environment to run some specific tests or tasks of your software lifecycle, but in my opinion that issue is beyond jenkins and concerns only the "deployment" phase of your lifecycle (ie. it's not a "Jenkins" issue, but an infrastructure issue that you should think about with a more general approach, and then simply tell jenkins where to deploy).
This question is just arising out of curiosity. Everyone now a days use jenkins for build and deployment automation, but still many of these people shy away from using the jenkins for Production deployment.
Considering Jenkins is such a nice and easy tool, I don't really understand why we don't see more of Jenkins in production deployment. Is it because of some security reasons? If yes, what these security reasons might be?
Or any other reason which exists that make some people to have 2 different tools for automation, one for dev and lower environment and another for higher environment like production.
System Admins running Production environments don't want to be obsoleted/automated out of their job by "Dev tools"
I might be bit late here but I would like to share an automated process that will allow you to handle the entire production Deployment using a single YAML file.
For more information
https://github.com/frostyaxe/Blaze-Tracker
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx