Our group integrates a bunch of different sub-blocks into our main project and we are trying to determine the best way to manage all of these different pieces of intellectual property. (From here on out I will refer to these sub-projects as pieces of IP "Intellectual Property").
The IP will be a mixture of third party vendor IP, previous projects IP and new to this project IP. Here are some of the ideas we are considering for managing all the different pieces of IP:
Publish releases on a physical drive and have the main project point to the correct releases.
PROS - Little to no dependencies on the SCM: seems simpler to manage initially:
CONS - Must remember to keep each physical design center up to date:
Use Perforce client spec views to include the correct version.
PROS - Able to quickly see what IPs are being used in the client spec:
CONS - With a lot of IPs the client spec becomes very messy and hard to manage: each team member manages there own client spec (inconsistencies): the very thing determining which IP version to use is not under SCM (by default):
Integrate the the different releases into a single one line client view.
PROS - Makes client spec maintenance dead simple: any change to the IP version is easly observable with the standard Perforce tools:
CONS - Not as easy to see what versions of IP we are using:
Our manager prefers #2 because it is easiest for him to look at a client spec and know all the IPs we are using and the versions. The worker bees tend to strongly dislike this one as it means we have to try and keep everyones individual client specs up to date and is not under SCM of the project itself.
How do others handle IP within a Perforce project and what recommendations do you have?
UPDATE:
I am really leaning towards solution #3, it just seems so much cleaner and easier to maintain. If any one can think of why #3 is not a good idea please let me know.
I would go for the third solution too.
I can't think of any downsides, and have not experienced any when faced with similar situations in the past.
You could placate your manager by using a branch spec that clearly spells out which IP versions are branched in. He could then refer to that branch spec instead of a client spec.
Also if you look up 'spec depots' in the help, you can set Perforce up so that it version controls all specs, including branch specs, automatically, which will give you traceability if you alter IP versions.
"each team member manages there own client spec (inconsistencies)"
Don't do that. Have the client spec be a file that is checked in to Perforce.
I would suggest #2 as it is the most transparent system. Yes it will mean some more work keeping clients up to date, but you can minimize that issue by using template clients.
At my work we use template clients that the devs copy from to keep their clients properly configured. We name this with the pattern "0-PRODUCT-BRANCH" (and sometimes add platform if needed). Then it is a one line command from the command line, or a couple clicks from the GUI to update your client. I send notices to the team whenever the template changes.
Now in my case, template changes don't happen very often. There is maybe a max of 5-6 per year, so the hassle level may be different for you.
Related
Using a lot of (official and non official) terraform providers, I'm looking for a tool to perform security analysis on terraform providers before executing terraform plan/apply commands (and so executing providers code). I want to prevent malicious code from providers to be executed blindly.
I'm basically executing terraform providers mirror command to save local copies of required providers and I'm wondering if I can security scan that result.
I tested kics, checkov and tfsec but they are all looking for security issues in my terraform static code but not in providers.
Do you have any good advices regarding this topic ?
This is actually quite a good question. There are many other problems that can be reduced to same generic question - how to make sure that the thing you downloaded from the internet does not do anything malicious to you like e.g.:
How to make sure that a minecraft plugin does not hack you?
How to make sure that a spring boot dependency does not hack you?
How to make sure that a library xxx you attach to your project does not do harm to you?
Should you use docker image yyy in your project?
Truth is: everything you use has the potential to explode right in your face (or more correctly: right into the face of the system owner). That's why the system owner (usually a company) defines a set of rules to follow what is allowed and what is not allowed. No set of rules you are aware of? Below a set of rules we came up with ourselves when thinking about on-boarding a new library for some projects to use:
Do not take random stuff from github. Take only products with longer history, small bug backlog, little to none past issues in the CVE list, actively maintained.
Do static code analysis yourself. Sometimes it is possible to have tools that work on binaries level do that for you. Sometimes you can do it on source level only. In case of Java libraries, check what tools like Dependency Track think about the library and version you are about to use.
Run the code and see how it works: what does it write, what does it read, what URLs does it communicate with (do a TCP dump if necessary).
Document everything you have done somewhere.
This gives you no 100% confidence that things will not go terribly wrong. But this is a systematic approach that will reduce the risk of doing something stupid.
I would like to share a project\solution with two teams, ideally on two TFS.
The option to have both teams using the same TFS doesn't work, because both teams don't have access to one of the TFS and hosting the solution on this TFS is a requirement.
It looks as follows:
Project\solution -> Team1 -> TFS1 (requirement)
Same Project\solution -> Team1 + Team2 -> TFS2 (???)
What are my options? Is there a tool out there that can do this? Should I use tow different version control packages?
You can use TFS Integration Plataform to sync the Team Projects between the TFS's installs... But the best world is: access one TFS trought TFS Proxy.
Another way is use Git repository, you will can sync remote the repository with your repository, but access the work items just by TFS.
There are really three ways to solve your problem. The reality is that only #1 is effective if you can't use the cloud. Note that using #3 is fraught with pain and suffering. Aa with all dark side hack/workarounds nothing meets the needs like solving the underlying problem rather than sweeping it under the carpet.
All access - the only really viable solution I to give all required users access to the TFS Server. I have worked with healthcare, banking, defence, and even Insurance. In all cases, in all companies, you can have a single server where all required users can access. In some cases it is hard and fraught with beurocracy but ultimately it can be done.
Visual Studio Online - while there is fear of the cloud this is likely your only option if you have externals that really can't directly access your network. This would be that common server. If you are in Europe then MS has just signed an agreement that ostensibly puts EU located servers for an American company outside of the reach of the Partiot Act (untested.) You can also easily use the TFS Integration Tools to create a one way sync between VSO and your local server.
Bi-directional synchronization - this can be achieved in many ways but there is always a penalty in merging if you have changes on both ends. You can use the TFS Integration Tools that are free or use a Commercially available tool like OpsHub. If your are using Git as your repository within TFS then you can use the command line to push source between two servers... Even if the can't communicate by using a USB stick.
Use #1 or #2 and only as a temporary and short term measure ever use #3
I use the tools all the time to move one way only from one system to another and even this a is a complicated experience. To move stuff bi-directionally you will need a full time resource to resolve conflicts.
If the servers can communicate with each other you may be able to use a system (akin to) replication. There is one master Tfs instance and then external sites use a proxy to allow the second team to work without direct or always-available access to the main server.
Alternatively you may be able to use branches - you could keep a branch for the external team's code and then merge to or from that branch to your mainline. In this scheme you would be able to sync the code by copying between the branch and external site, so you could even transfer updates on memory sticks if there is no direct net connection. Each sync would be pretty time consuming though, as someone on your main server team would have to merge code back and forth through the branch.
Another thing to consider is whether there is any way you can divide up the codebase and the tasks to minimise the overlap between the two teams. for example if one team provides a library that the other uses. This is just too minimise the merging needed.
At the moment support requests / bug reports made by customers are coming in by mail. It is getting harder to organize priorities and stay at the helm of all this. So I am looking for bugtracking(?) tools. Not all reports are bugs of course, sometimes it's just feature request or support requests.
So my question is: whicht open source bugtracker / support request handling tool do you recommend? I know Mantis which seems to be my front runner for a more elaborate evaluation, but I already worked with it (as a reporter / contributor) and found the GUI a little cumbersome. Another issue is that I thought about using the tool for multiple website projects of different customers.
Intuitively I would prefer to run only one instance of the tool for all projects to have a better overview of all critical issues (independently of the project). Of course customer A should not be able to see customer Bs request (but every customer can have multiple reporting accounts) Is Mantis able to handle that? Can you recommend any other alternatives?
P.S.: I heard about Jira, but I will try to find a free tool for my first try.
It's possible to use email with Mantis, so that you can get incoming email (directly or by forwarding) to Mantis.
Then you can have a workflow in Mantis, f.ex. have an incoming project and customer projects, and you can send email with bcc Mantis and subject containing issue number (I use [1234] as a pattern).
I haven't used other issue trackers as much, but my experience with a customized Mantis is good regarding different kinds of issues and using with email.
Since you're turned to Open source, I'd say install a project management platform like Launchpad, redmine... etc and then create a project for each of your clients (of course you can have multiple accounts for only one client). The bug tracker in these platforms can serve as a support request service.
I'd go for Launchpad because it also has the Q/A feature and blueprints, and is also nice looking and very very user-friendly. And also damn easy to install on a Ubuntu Server.
Kind regards
I have a number of Windows servers at work that are used for staging web sites for clients while they are being created.
I wanted to start using versioning on them so that when we work with outside vendors on a project, if/when they overwrite my work, I'd like to be able to go back and get the version before.
My question is that I think I'm not looking for the correct terms in searching for information, but what kind of resources are there to learn how to install the software for versioning or a site to help me get started.
Any and all suggestions would be appreciated.
Steph
Since your development workflow can be decentralized (as in "there isn't always one central repository), DVCS tools, with their common tasks described here) can be more adapted.
Git-Scm
Mercurial (see HgInit.com for a very good tutorial like the kind you are after)
Plastic SCM (which has a DVCS nature)
A friend of mine and I are developing a web server for system administration in perl, similar to webmin. We have a setup a linux box with the current version of the server working, along with other open source web products like webmail, calendar, inventory management system and more.
Currently, the code is not under revision control and we're just doing periodic snapshots.
We would like to put the code under revision control.
My question is what will be a good way to set this up and software solution to use:
One solution i can think of is to set up the root of the project which is currently on the linux box to be the root of the repository a well. And we will check out the code on our personal machines, work on it, commit and test the result.
Any other ideas, approaches?
Thanks a lot,
Spasski
Version Control with Subversion covers many fundamental version control concepts in addition to being the authority on Subversion itself. If you read the first chapter, you might get a good idea on how to set things up.
In your case, it sounds like you're making the actual development on the live system. This doesn't really matter as far as a version control system is concerned. In your case, you can still use Subversion for:
Committing as a means of backing up your code and updating your repository with working changes. Make a habit of committing after testing, so there are as few broken commits as possible.
Tagging as a means of keeping track of what you do. When you've added a feature, make a tag. This way you can easily revert to "before we implemented X" if necessary.
Branching to developt larger chunks of changes. If a feature takes several days to develop, you might want to commit during development, but not to the trunk, since you are then committing something that is only half finished. In this case, you should commit to a branch.
Where you create a repository doesn't really matter, but you should only place working copies where they are actually usable. In your case, it sounds like the live server is the only such place.
For a more light-weight solution, with less overhead, where any folder anywhere can be a repository, you might want to use Bazaar instead. Bazaar is a more flexible version control system than Subversion, and might suit your needs better. With Bazaar, you could make a repository of your live system instead of setting up a repository somewhere else, but still follow the 3 guidelines above.
How many webapp instances can you run?
You shouldn't commit untested code, or make commits from a machine that can't run your code. Though you can push to backup clones if you like.