We have Dev, QA pre_prod (stage) and Prod(Trunk) branch.
This is how our process works , please help in improving process to avail CI&CD features using TFS..
Dev changes are merged to QA branch on schedule basis say end of sprint. then published from QA branch. QA team does testing if found any defect , then bug-fix is done in QA branch then get merged with Dev branch.
if QA is done then QA branch is merged with pre-Prod and Acceptance testing is done by client then merged to prod branch and published to client.
if it comes production bug, hot fix is made in pre-prod branch -> published for acceptance testing (acceptance env where QA gets notified) ->all good then then merge to prod branch and publish to client.
hot fix is not merged to QA as it may add other QA ongoing check-ins. since hot fix needs instant fix it goes through Acceptane testing directly where QA also can test .. if all good then get merged to QA branch.
Cons:
1. All development has to be done to give build to QA . so QA is idle. no CI.
2. Another team to do merging between branches. publish it and if error again merging it. resource not free...
how can we implement TFS CI& CD features here ?
CI better works with one branch pattern where check-in will trigger build then QA will test and approve then promote to prod. but here if QA rejects then dev has to fix since it is single branch it will get merge with ongoing daily check-ins and if triggers some more error in QA the this cycle will repeat all the time and features can't be promoted to prod.
Second solution could be to establish branch specific CI & CD as changes are done in individual branch. but here we can't avail the CD feature.... as there is no link between environments ...
third concern is QA needs a stable environment to test all tasks..if in mid new deployment is added through CD then QA testing will get hampered.
please help...and provide your thoughts to it if process needs to be changed...
Related
I'm working with BitBucket and VSTS to build a standard CI pipeline.
Development team works on a feature branch. When their work is complete, they merge their code into development branch.
I would like a way to enforce a test execution prior to merging the feature branch into development branch. Ideal situation would be something like this:
The developer creates a pull request.
The code review process is approved.
The developer does SOMETHING, which triggers some process that merges the feature branch with the development branch (feature branch could merge into development branch, or a brand new branch is created with the two branches merged, or something else).
The merged branch is built, deployed, and test executed against it.
Test pass: branch is merged into development branch.
Test fail: feature branch does not merge into development branch (if the branch is already merged into development branch, then the merged commit is reverted out of development branch).
The goal of this process is to keep development branch at a "good" condition.
Typically, the SOMETHING which triggers all this process is the act of committing (or merging) a code into the development branch. The trouble with this process is reverting the code out of the development branch if the tests fail without loosing the code. (It's possible that the merged branch has been deleted at this point).
There is build Pull Request feature in VSTS build, so you can create a new build definition with Build pull requests enabled, then the build will be triggered once a new pull request be created and match the target branch, you can check the build result in pull request in bitbucket.
You can define the policies through checklist: Pull request guidelines for Bitbucket Cloud.
BTW, the VSTS includes branch policies feature, so you can consider using VSTS repository.
Im creating Jenkins pipeline for building and deploying our app.
I want to have the same build for the staging and production environment(buld-once-deploy-many approach).
Merging feature branch into staging branch would build an app for both staging and production, but it will deploy it only to staging bucket.
After testing, it would be good that developers merge the staging branch into master which will take the previous staging build and deploy it to production.
Alternative would be to have one branch, and devs would manually trigger another job on Jenkins that would deploy the build to production.
I want to avoid devs going into jenkins and triggering build, since most of them find it intimidating, there are also some nasty vpn configuration steps they need to go through to have access to Jenkins etc.
Would this be a bad practice? Do you have any suggestions how to achieve something like this?
Thanks
This is more of a devops question than a Jenkins question, but here is my take...
I can't decide if you are saying that you would re-build from the master branch, or only use the commit to the master branch to trigger a deployment of the original staging artifact. So I'll address both.
For this situation:
If you build an artifact in a staging branch, and test it. Everything looks green on the tests. So you merge those changes to another branch, re-build, and deploy to production.
The problem: Can you be 100% sure that there was nothing else in the master branch that is not different than what was built AND tested in staging?
You are risking the jello view anti-pattern because unknown and untested changes could sneak into your production artifact. It becomes terribly difficult to troubleshoot why it worked fine it staging, but now fails in production.
For the second situation:
If you are saying that you wouldn't rebuild from the master branch, then merging back to master doesn't buy you anything except a trigger to kick off a new build, because you are never generating an artifact from Master.
If you are going to to it this way, I think you could commit to a single branch, and then tag a release that is meant to go to production, then trigger off of the tag.
Either way, this seems like a strange pattern, and would be difficult to accomplish in an automated fashion in Jenkins. Somehow the newly triggered build would have to find the previously built artifact and deploy that to production.
Possible solution:
There are a few ways to solve this, but one of the easiest is to build once and deploy the same artifact all the way down the line, as you mentioned as an alternative option. But this would likely require some approvals or additional triggering in Jenkins.
If you don't want developers to have to touch Jenkins, then the more likely solution is to build and run your unit tests and smoke tests on the staging environment. Then when a developer wants to promote a build to production, they commit it to the master branch, where the same build is kicked off, and testing is all performed again, in addition to more advanced integration, functional, and acceptance testing. If it doesn't pass, it doesn't go to production.
Your initial tests in staging give the developer quick feedback, but don't serve as the official tests, which only run on the production build.
With a pipeline script, you could easily accomplish this with a single Jenkinsfile and single multibranch pipeline job with stages that are only run when the branch pattern matches.
stage ("Acceptance Testing" ) {
when { branch "master" }
echo "Do testing here"
}
Is it possible to run an Automated Build when you Merge a Feature Branch into the Development Branch?
When a Developer is done working on their Feature Branch, they will Merge the Feature Branch into the Development Branch. When it is Merge, I would like to fire off an Automated Build, that will run the Unit Tests.
With Continuous Integration, you run the Build when you check in a Changeset. I want to run Continuous Integration when I Merge a Branch into another Branch.
This isn't much different than setting up a build for a normal check in. You would just set up a trigger/build definition on the appropriate branch for the approriate reason. Once the merge is performed into the branch and checked in, this would trigger the build normally.
From my source view see:
KritnerWebsite is trunk, KritnerWebsite-branch is my dev branch.
I complete development/check-ins on the branch, then when done I merge into trunk. At which point the following build definition takes over:
Notice in above the monitored folder for the trigger (in this case gated check in) is my trunk folder in source control.
Hope this helps! :)
FYI a merge isn't actually a "merge" until you check it in and it becomes a changeset. When doing a merge, it actually just gets merged locally - into your workspace. You could technically do a local build at this point, but your build definition won't take over until you actually check it in. I'm not sure why Daniel felt this isn't an answer... as it's the same thing I went through when setting up build definitions for merges - but oh well.
Looking for a process to disable and archive CI jobs on DEV branches that have merged to production and are no longer needed.
Currently our process is:
After a release, find out which branches will be in the next release
Set up jobs for those branches
When the next release occurs, check with the developer of the branch to confirm completion
This is very manual and somewhat simple. If anyone else has ideas on how to do this, please let me know.
Looking for advice on how to handle this scenerio.
We have 3 environments: Dev, QA and Production.
Currently pushing the code to each environment is a manual process, wondering how something like Cruisecontrol or TeamCity could streamline this process.
How can we push to the various environments in an automated way?
How should TFS be setup to make this happen? i.e. master branch, feature branches etc.
Scenerio:
Developer#1 pushes their changes to the Dev and QA servers.
Developer#2 pushes their changes to the Dev and QA servers.
Now we need to only push Developer#1's changes to production.
Should the main branch have only the code that should be going to production?
To control what gets pushed to each environment KMoraz's approach would be the correct one, using branches and merging.
Now, for build and deployment automation the latest setup I've been using is with Team City.
My setup is:
Trunk build: compiles on every commit, runs all unit tests, generates code coverage reports, runs FxCop
Static analysis build: runs nightly against Trunk, executing Duplicate Finder (Team City), ConQAT code clone analysis, StatSVN, and Resharper Code Inspections (Team City)
DEV Deployment (dependency on Trunk build): on every commit, if the Trunk build is successful, the application is automatically deployed to a DEV environment, using MS WebDeploy with config transformations.
QA Deployment: triggered manually through Team City's interface (click of a button), when moving to QA. Deploys the application to the QA server using MS WebDeploy with config transformations.
You would also set up builds for different branches, depending on your needs, especially for branches created for releases of stable versions.
The key part, is having different visual studio build configurations (just as you have "Release" and "Debug", you should have "Dev", "QA", etc), which you should use along with web.config transformations in order to get WebDeploy to configure your environment for you.
That way you'd have different web.Dev.config, web.QA.config transformations, one for each build configuration, with specific settings.
There's an excellent series of posts by Troy Hunt called "You're deploying it wrong!" which guides you through the setup of automated builds and deployments.
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
It was very useful to me when setting this up.
Now we need to only push Developer#1's changes to production.
-Developer #1 checked-in his code to the Dev branch. After QA verified his changes, now you merge the changes to the Main branch and build a release for production from the Main.
Should the main branch have only the code that should be going to
production?
-Yes. Ideally, production releases should be built from the Main branch.
How can we push to the various environments in an automated way?
-In TFS, a common practice is defining a build defintion per branch and/or build type. Apart from the source and build type, each defintion can also have its own tasks, I.e: run unit tests, publish to certain folders, deploy build artifacts to Lab Management, etc.
ProjectName-Main-Gated
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI