Right now you might not see much need for a single repository design. Later, you may find your opinion changes.
You might want to use a single repository if
you need to keep your different projects in sync. It's more difficult to keep separate repositories in sync than a single repository.
your team members will need to switch between ...
I believe its a very good practice, In my company we do exactly the same, I assume this is only because of historical reasons (in our case) but in general, you will try to have the smallest number of the system possible so for the medium future, it probably makes sense to unify test automation script with the source code as the same version.
Adding to the awesome and very detailed existing answers. There is a well-known success story of using a single large repository - Facebook and Google. As of 2014, Facebook's main repository was 54 GB in size. As of 2016, Google's main repository had 35 millions commits.
One of the most important advantages of having a single repo is atomic commits across ...
Running all tests at once is something that a Continuous Integration server should do for you, not something you do manual as it lets you wait for a long time. Let a server do the work and reporting.
Multiple repo's have the following advantages:
Easier to schedule parallel-runs in a CI. Will be faster. (technically also possible with a single repo, but ...
The big advantage of synchronizing both the source code and the test code version is that you can easily go back in time within your VCS by using tags (see e.g. Git or SVN), allowing you to qickly check out the sources and tests for a specific version.
Personally, I am a huge fan of Semantic Versioning, which you can summarize as follows:
Given a version ...
I would apply KISS and YAGNI principle: Keep It Simple, and You Ain't Gonna Need It.
Start with one, and split into separate repositories when you can see the business need for it, and benefits.
I agree with @KatePaulk with pros and cons, but when no obvious benefits, I would go with simpler solution: single repository.
Stop using separate branches for your test code. Test automation code is part of the solution, just like the 'real' , product code. The test code will not have its own version. It will have the same version as the product code by definition. No need to sync 2 versions. That's how we do it and we've never done it in another way.
In my opinion, a wonderful idea.
As the version progresses, it will be necessary to make changes and adjustments so that the actual code of the automation will also increase the number of versions.
If there is transparency to customers it looks much better and makes an order.
Update what was decided at the end, interesting :)
Why did you write those automated tests? Do your developers have interest in information your script collects? if yes - great! ask them for help to set the things up. If not, that I would start with the question: are your automated scripts delivering any value?
I used Jenkins as well and this was my way of kicking off:
create automated scripts
push into ...
I haven't used TeamCity (I use Jenkins) but this sounds like a pretty straightforward and common use case for any CI (Continuous Integration) system. Start by learning the basics of TeamCity. Some terminology that might be helpful in your research (note that these are Jenkins terms and may differ slightly for TeamCity):
It sounds like you want to configure ...
The main purpose of code review is learning (yes, cross-validation/static testing is secondary).
Considering there no significative difference of knowledge of different parts of the application between the sub-teams:
You could use code review as a static testing tool within the locals teams (increasing feedback speed) and as a learning tool for the remote ...
Bugzilla for issue / bug tracking; Bugzilla wiki link
TeamCity for build and deployment; TeamCity wiki link
Octopus Deploy for automated deployment; really good if you are working with .NET Octopus Deploy wiki link
QAComplete for issue / bug tracking; the best choice if you are using SopaUI or test complete. TestComplete link
Trello for task management, ...
Most shops I know keep the tests in the same codebase as the programs and so under the same source code control mechanisms.
The tests are run when code is pushed (both master and branches for developers).
Please be more specific about what you need.
I would setup a Jenkins free-style job and execute the java based Se Interpreter from a shell-script task
Setup free-style Jenkins build
Schedule build with github with the git-plugin to run job on each commit
Add a shell-script that runs the Se Interpeter in the build and make sure it has a correct exit code to fail/success the run or see this question for ...