My understanding is if the bug was in Activity, the new code will be used since Activity does not have the concept of version. But what if there is a bug in Workflow code and causing some workflows to fail (or even worse, not fail but stuck), we fixed the bug and deployed the new version, but those failing workflows are stuck on old versions. Is there a way to automatically move those failed / stuck workflows to new version and re-run them?
This happening a lot to us because we just started to learn to use Cadence/Temporal
Thank you in advance!
It depends on the bug.
For bugs that cause workflow to get stuck (in Go a nil pointer dereferencing causes panic which blocks the workflow progress by default) deploying the new version of the code is usually enough to unblock them.
If the bugfix requires backwards incompatible change then the best option would be to reset workflow to the point before the bug. This way workflow will be rolled back and continue through the new code.
For situation when the breakage of workflow code is caused by a new bad build you can rollback the workers to the previous build and mark that build as broken and all workflows going to roll back their state to before that build automatically. See "Recovery from bad deployment" section of the Temporal documentation.
If you are using ElasticSearch integration then you can also perform batch reset of multiple workflows using a predicate to select workflows that match some criteria. See "Signal, cancel, terminate workflows as a batch job" section. Besides the name of the section the batch jobs apply to reset operations as well.
Related
I have an issue in JIRA that is following one workflow, workflow looks something like this (for bugs):
New -> Eval -> Approve -> Roadmap/Schedule -> Dev -> Complete
This workflow is for issue type "Bug".
For higher priority bugs, I want a totally different workflow, and for it to have its own issue type, for instance "Priority Bug".
R&D -> Dev -> Release -> Complete
This works great, for new Priority Bugs, but I have a transition, that allows you to promote a normal bug to a priority bug. That transition changes the issue type to Priority Bug properly, but when it gets there, it seems lost, its now not in either workflow. How do I get it to change workflows as well?
I suggest to install Script Runner plugin, and implement this as a single workflow. You can have custom scripted conditions that will check the type of the issue and allow and disallow your transitions thus emulating like it is a different workflow for another issue type.
Workflows are for a given project and for a given issue type. If the bug is in a particular project and of a particular issue type then it will follow the corresponding workflow.
However, when moving from one workflow to another there needs to be some way for JIRA to know what state to go to. When you do a manual move you get a prompt that allows you to decide what state in the new workflow it has. I have never done an automatic move triggered by a transition, but I suspect it will have a problem determining what state the issue should have. Perhaps you could set the state as a part of the transition?
After reading and asking about how to deal with git, Github, branching, versioning and tagging, it looks like the best way to denote a new version of software, is by marking the last commit of a specific version with a specific tag.
A structure like this can be assumed:
Commit 1
Commit 2: Tag 1.0.0
Commit 3
Commit 4
Commit 5: Tag 1.1.0
Commit 6: Tag 1.1.0
Where once version 2.0.0 is released, most likely a 1.1.x branch is created to maintain the 1.1 release for hotfixes, etc.
Now I am wondering how it is possible to integrate this with a CI, like Travis for example.
What I do know is that:
A Continuous Integration system, like Travis CI, gets triggered on every commit to any branch, and it is possible to enable/disable this per branch.
I am struggling to figure out if it possible at all to start a build once you have tagged a certain commit, can anyone explain me how this can work?
The idea behind Travis and Continuous Integration systems in general is that first word: Continuous. You want it running on every commit because your tests should always be working (except when you know they're not). Running it on each tag isn't very CI-like, as it prevents the continuous part from happening, and defeats the entire point of it.
CI allows developers to catch bugs before they might've been noticed, even if your contribution docs say that you're supposed to have the build passing before pushing doesn't mean people listen. Travis, in particular, allows for lots of variation and multiple builds per commit with different setups, so you can test for a case that you might not think of when developing locally.
If you really just want to run it on each tag, you could write your build script to exit early if there wasn't a new tag defined. Travis defines a bunch of environment variables that could help you detect it.
This trips up a lot of newcomers to TFS, and I'm keen to hear your solutions.
So you've fixed a bug, tested it, looks good, everyone is on top of you to get it out as soon as possible, so you queue a new remote build, wait patiently, then put it into test/production only to find out it's actually an old version - you forgot to check in before doing the build!!
OK, so this is a common oversight, and it costs valuable time. Is it possible to pop up a warning first, or is there some neat trick other have found to avoid this?
Instead of manually kicking off a build after you check-in, what if you set up a "Continuous Integration" build so that the build would be automatically kicked off once you checked in? This way it would be impossible to forget to check in your changes. Here is an article on how you can set that up: http://msdn.microsoft.com/en-us/library/bb668971.aspx.
Continous Integration as mentioned above is the best solution! :)
But you could write a custom activity within your build definition to check if there were any new changesets since the last build and if there is no new changeset show a warning message in the build log or something, but then again the developer has to read to log otherwise it's not useful.
I wouldnt spend any time at all for something like this, I would rather knock on the developers head everytime he misses the check-in! :}
a bit of background first...
I am setting up a versioning numbering system for our project which currently only has a development branch, but we are now moving towards our first deployment. We are using TFS and we use nightly builds on our dev branch.
The way we are probably going to go with this is that when we get ready for a release we take a branch off dev and call it 1.x. This shall be a test branch: we test it, fix it (then merge back to dev), test it some more then when it is all good we take another branch off the 1.x branch and call it 1.0. It is this branch that gets deployed to production. Any fixes in production will be made to the 1.x, tested and then a new branch 1.1 will be made.
My issue is with the testing of the 1.x branch. Before testing the branch will be locked for obvious reasons. My issue is that QA requires that a round of testing be conducted against a "version number" and if testing fails the next round of testing will be against a new "version number." Us developers want to tie the "version number" to the release and testing can iterate over that version...so there is a conflict here.
My first thought is to use the build number as the point in time that the code is tested against. When its time to submit a new version for testing, the 1.x branch is locked again and a build is kicked off and the VSTS number that is generated becomes a "release condidate 1 for v1.0." Mapping the RC to a build we can do manually in a spreadsheet...
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
I am now confused about what is the best way to go here. Is using a build number for a release candidate enough? Does manually labelling serve any purpose here (the only benefit I can see is that we can give it out own name and description)? Can I tell TFS NOT to create a label whenever it runs a build and just do all our own labelling at significant points in time (not every build is going to be a release candidate for example)? If so, is NOT creating a label after each build a bad idea, what does labelling give me?
I guess I am confused about where changsets, build numbers/names and labels all fit in with one another...
This is a broad question but its one of those ones where I am not 100% sure what to ask. Any help appreciated.
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
What you have read is correct. With TFS (unlike, say, SourceSafe), every server action constitutes a 'known point in time' which can later be referred to. You can see what I mean by doing a Get Specific Version... and looking in the Version dropdown: in TFS 2005 the relevant ones I see are Changeset, Date, Label. Now, as you correctly say, every build automatically creates a label. This means that at any future time it will be possible to retrieve the code exactly as it was after any given changeset; at any given date; and when any specific label was applied, thus including when any build was done.
The upshot is that you can use your own labels or not, entirely at your own discretion - the ability to retrieve a given snapshot of the code will be there anyway. I wouldn't suggest trying to inhibit TFS from producing a label for each build (I don't know if this is even possible) - labels cost you nothing.
Your branch 1.x is a consolidation branch which will contain many incremental small evolutions.
Locking the branch is not the answer.
Setting a label (specifically named "for QA test", and locked in order to not be able to move that label, is the usual way to signal the QA team they can build their own workspace and retrieve that exact label.
Then they can begin their tests against the code.
Creating a label after each build is not always practical, since not every build is meant to be tested by QA.
I am starting to get a reputation at work as the "guy who breaks the builds".
The problem is not that I am writing dodgy code, but when it comes to checking my fixes back into source control, it all goes wrong.
I am regularly doing stupid things like :
forgetting to add new files
accidentally checking in code for a half fixed bug along with another bug fix
forgetting to save the files in VS before checking them in
I need to develop some habits / tools to stop this.
What do you regularly do to ensure the code you check in is correct and is what needs to go in?
Edit
I forgot to mention that things can get pretty chaotic in this place. I quite often have two or three things that Im working on in the same code base at any one time. When I check in I will only really want to check in one of those things.
A few suggestions:
try work on one issue at a time. It's easy to make unrelated changes to the codebase that then end up being committed as one big chunk with a poor log message. Git is excels here since you can so easily move switch branches, and stash and cherry pick changes.
run the status command before a commit to see which files you've touched and if you've created new files that need to be added to version control.
run the diff command to see what you've actually changed. Often times you find that you've left in some debug logging that should be taken out or made some unnecessary change that is just cluttering up the diff. Try to make your diffs as small and clean as possible.
make sure your working copy builds with your changes in it
update before checking in and make sure that your working copy builds with other peoples changes in it
run what ever smoke test suite you might have to make sure that your changes work correctly
make small and frequent commits. It's a lot easier to figure out what has broken the build when the breaking commit is small.
Other things that the team can do is setup a continuous integration server like David M suggested so that the broken build is discovered as soon as possibly and automatically.
I usually always do a Get Latest before, then build. If build is good then I check in my code.
Here is what I have been doing. I have used ClearCase and CVS in the past for source control, and most recently I have been using Subversion and Visual Studio 2008 as my IDE.
Make my code changes and build on the local machine.
Make sure they do, in fact, fix the bug in question.
Run an SVN update on the local machine and repeat steps 1 and 2.
Run through the automated unit tests to verify that they pass.
If an automated smoke test is available, which automatically tests a lot of the system's capabilities, run it. Verify that the results are correct.
Then go to the build machine and run the build script.
If the project's configuration has changed, this could definitely break a build. Perform an SVN update on the build machine, whether the build script does that or not. Open the build machine's copy of the IDE, and do a complete rebuild. This will show you whether the build box has any problems that you have taken care of on your machine but not on the build box.
The suggestions to keep separate branches for each issue are also very good, if you can keep track of all of the issues you are working on.
First, use multiple working copies (a.k.a sandboxes) - one per issue. So, if you've been working on some complex feature for a while, and you need to deal with a quick bug fix on the same project, check out a new clean working copy and do the bug fix there. With independent working copies for each issue there is no confusion about which changes to commit from the working copy to the reposistory.
Second, before committing changes, always perform the following three steps:
Buld the software.
Run a smoke test (does it start and run without crashing).
Inspect the changes you're checking in by diffing your changes against the baseline.
These should be repeated after any merge operations (e.g. after an SVN update).
At my workplace, the safety net for this is peer review. That is, get someone else to build, run, and reproduce your solution on their machine, on their view.
I cannot recommend this enough. It has caught so many omissions, would-be problems, and other accidental pieces of junk to make it a valuable part of the process. Not to mention that the mere knowledge that you have to place your work in front of someone else before having it go on to the main branch means that you raise your own quality standards.
In the past I have used branching in Clear Case to help with this issue. The process I used is below. I've never used SorceDepot so I do not know how this can be adapted to work with it.
Create a branch for the bug fix
Code all changes on the branch
Code Review
Merge to stable branch in a different view (the different view is important)
BEFORE checking in: compile, test, and run
Check in code to stable branch
By creating the branch and then merging the changes to a different view (I use Merge Manager to do the merge) any files that were not included or checked in immediately cause issues. This way everything gets tested as it will be when checked in on the stable branch.
The best thing to avoid your problems, is to use hooks, that are provided in most SCMs (they are for sure in SVN and Mercurial, and I believe they must be in other advanced SCMs). Attach unit tests to the hook and make it run every time someone checks code in - exactly before it is checked in. This way you will achieve two things:
code in SCM repo will always pass the tests,
you won't make most simple mistakes, because they should be easily detectable, if you have decent test suite.
I like having Tortoise plugins for Windows Explorer. The file icons are all badged with committed, modified or not added icons making it very easy to see what status the files are in. I also enable the meta data for Modified so I can sort changed files in the list (Details) view, where they bubble to the top so I can see them.
I bet there is a Tortoise* plugin for your SCM, I saw one for Mercurial and SVN (and CVS, ugh). I really wish Mac OS X's Finder would accept plugins like Tortoise, its so much easier than having to pop open a dedicated app most of the time.
Get someone else to go through "every" change "before" you check in the code.