I'm making a deployment diagram in UML for a windows application software. I wanted to know if an installer is an artifact and how should I draw the diagram exactly?
Do I only put the installer inside the node that represents a client machine, or I put not only the installer, but the components that it installs in association with installer?
Artifacts physically represent your components. A component is a logically consistent part of your application.
So you have an artifact for your installer only if it is a part of your project. I mean if you designed your own installer, then it is an artifact because it is a part of the "result" of your software project. Yet even in this case it may not be very useful to have it appear in a deployment diagram, because you typically do not deploy an installer...
Otherwise it will not be an artifact. You will have artifacts for your installed components, not the installer itself.
In UML terms your installer file is an artifact. Now whether you should or not show it in a diagram, it depends. A basic tenet of architecture documentation is that you should only produce architecture diagrams if there's anyone who'll benefit from it.
If the stakeholder of that diagram is someone who will install the software, then it may make sense to have the installer in the diagram.
If the stakeholder of the diagram is someone who will simply try to configure or fix issues on the installed application, then you'd probably better show the installed artifacts.
In any case, the proper way to show that an artifact is deployed to a node is using the <<deploy>>stereotyped dependency. Example (from UML 2.5 specs, Fig. 19.3):
Related
I have a solution that consists of 5 projects (ASP.net Core Webservice and dlls). For this solution I want to create a setup using WiX. I'm working with Visual Studio 2019.
The solution is located in a Git repository in Azure DevOps.
There is already an automated build process that is executed after each pull request.
I want to extend this process (or create an additional one) so that the setup is also created automatically after the build.
Should I add the setup as another project to the existing solution or should I create a separate solution?
I don't have any experience with creating build pipelines in AzureDevOps yet, so I'm afraid that I might run into problems there later if I choose the "wrong" variant now.
What are the advantages and disadvantages of the two variants?
Are there best practices for when to use which?
This is a matter of personal choice but after 20+ years of installation development I prefer two solutions. The reasons are:
Pros:
It helps organize the repos to have Application code and Installer code.
Application developers don't have to have WiX installed. Projects won't fail to load in the application solution.
The application sln can be updated to a newer version of Visual Studio without waiting for the installation toolset to support the new version. This has historically been an issue.
Project dependency / project build order issues are moot because all application projects will build before any installer projects will.
Application developers don't have to worry about installer developers messing up their projects.
Because the projects are in different solutions you can't use project references which can be tricky and brittle.
Building application first and using postbuild file copy commands to create a model helps define what the installer should look like.
Installation projects frequently have to consume files from projects that may not even use visual studio at all or a combination of both.
Cons:
Separating the code can lead to an "us vs them" situation between application developers and installation developers. However this can be mitigated by creating a clear understanding of roles and responsibilities. Nothing stops developers from being aware of and contributing to either solution.
A solution is a container that's used to organize one or more related code projects, for example a class library project and a corresponding test project. We'll look at the properties of a project and some of the files it can contain. We'll also create a reference from one project to another.
So if the WIX project relates to other projects in this solution, then add this setup as another project to the your existing solution.
I have used Eclipse for some time (just for general java development) and now I am trying to understand the added features that STS brings, and also learn Spring Boot development. I see that when I create a Spring Boot project it always wants me to select Maven or Gradle as the build tool but I'm not sure why or what that does.
I just don't fully understand what Maven is doing when I'm working in the environment. Eclipse always compiled the code and did other things for me by invoking the compiler and I never needed an external build tool like ant or Maven or whatever.
So is it just making a Maven configuration in case I want to build the application outside the Eclipse environment or does STS rely on an external build tool?
For small, "Hello world", projects simple Eclipse compile/debug is more than good enough.
Maven is "higher level" than "make/makefile" (the classic C/C++ build tool) or "ant/build.xml". Specifically:
Why maven? What are the benefits?
Henning:
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to
centralized POM.
getting a number of reports and metrics for a project
"for free" reduce the size of source distributions, because jars can
be pulled from a central location
Emmanuel Venisse
Lot of goals are available so it isn't necessary to develop some
specific build process part contrary to ANT we can reuse existing ANT
tasks in build process with antrun plugin
Jesse McConnell
Promotes modular design of code. by making it simple to manage
mulitple projects
it allows the design to be laid out into multiple
logical parts, weaving these parts together through the use of
dependency tracking in pom files.
Enforces modular design of code. it
is easy to pay lipservice to modular code, but when the code is in
seperate compiling projects it is impossible to cross pollinate
References between modules of code unless you specifically allow for
it in your dependency management... there is no 'I'll just do this now
and fix it later' implementations.
Dependency Management is clearly
declared. with the dependency management mechanism you have to try to
screw up your jar versioning...there is none of the classic problem of
'which version of this vendor jar is this?' And setting it up on an
existing project rips the top off of the existing mess if it exists
when you are forced to make 'unknown' versions in your repository to
get things up and running...that or lie to yourself that you know the
actual version of ABC.jar.
Strong typed life cycle there is a strong
defined lifecycle that a software system goes thru from the initiation
of a build to the end... and the users are allowed to mix and match
their system to the lifecycle instead of cobble together their own
lifecycle..
this has the additional benefit of allowing people to move
from one project to another and speak using the same vocabulary in
terms of software building
At an even higher level, Maven is a preferred build system for organizations interested in "ALM" ("Automated Lifecycle Management"), "CI" (Continuous Integration"), "CLM" ("Continuous Lifecycle Management") and/or "Devops":
https://www.ibm.com/developerworks/community/blogs/nfrsblog/entry/DevOps_best_practices_a_6_part_series?lang=en
DevOps (a clipped compound of "development" and "operations") is a
software development method that emphasizes communication,
collaboration (information sharing and web service usage),
integration, automation, and measurement of cooperation between
software developers and other IT professionals.[1][2] The method
acknowledges the interdependence of software development, quality
assurance, and IT operations, and aims to help an organization rapidly
produce software products and services and to improve operations
performance.
For "serious" projects, your organization (consisting of many developers, possibily distributed geographically) will integrate your project with a DevOps toolkit like Sonatype Nexus or Artifactory. Which, in turn, typically use Maven to automate project build and runtime dependencies.
But even for relatively "simple" Spring projects, you'll probably learn to appreciate the convenience Maven can bring to your builds (and corresponding JUnit tests).
How to build and deploy process from Eclipse to jbpm6 console? When I right click on JBPM6 project or BPMN process definition, there is no option of deploying.
Is there an ant script to generate deployable process archive from an eclipse jbpm6 project?
When I ask about Guvnor, people say its removed from Jbpm 6. Where do my deployment go then?
Is there a documentation about the structure of deployment file? Can I deploy my own web services/rest services/EJBs along with JBPM process?
Camunda has a very well documented process deployment model. I am expecting similar model from JBPM6, but there is very little documentation.
http://www.bpm-guide.de/2011/09/28/less-code-bpm-with-camunda-fox-server-activiti-and-jboss-as-7/
There was a huge change in technology in the project for the 6 release, so you need to wait until the final community version is out. Now guvnor was replaced by a different more up to date repository where now all your deployments go. The structure of a deployable artifact is a regular maven project, which make your life easier when you need to deal with dependencies between packages.
Please check the following URL to see the changes in the infrastructure:
http://blog.athico.com/2013/06/goodbye-guvnor-hello-drools-workbench.html
I'm new to osgi and wonder if it is possible to have a centralized mechanism to update, install or remove bundles.
Yes. You can do this programmatically, which means there are a large number of bundles that provide you out-of-the-box solutions. It is so easy (and so much fun) that for many people one of their first bundles is a little "management agent" (as the OSGi specification calls this part).
The absolute simplest solution is Apache File Install. It tracks a directory and installs/uninstalls from there. Couple this to Google Drive or Dropbox and you have a large scale fully automated deploy model (it also handles configuration, which is quite important).
The OSGi specification now has an OSGi Bundle Repository (OBR) specification. This is a very powerful model to describe dependencies (not just bundles) that allow management agents to calculate/leverage dependencies. This is supported out of the box on Felix.
There are a myriad of solutions that manage OSGi frameworks. There is commercial support with Paremus, IBM Tivoli, ProSyst and many others. And open source with Apache ACE and fusebundles.
There are two general ways to do that: Have you application to 'pull' bundles from a repository hosting bundles and update itself, or have an external provisioning application 'push' bundles to your application.
For pull solutions I'd say there is:
Eclipse P2 Used by the update manager of Eclipse. Mature, stable, but can be a bit tricky to get into, also I'm not sure if P2 works with other OSGi runtimes than Eclipse Equinox
Apache Bundle Repository (OBR) A bit easier, and it's in the OSGi spec.
For push solutions I'd say have a look at Apache Ace, from your question I think that is closest to what you want to do.
I'm trying to get my head around some of the concepts and I understand what a profile is and what an installable unit (IU) is but I'm struggling with plugins and features. Does anyone have any insight. How do they relate to profiles and IUs?
Thanks in advance,
Chris.
From eclipse wiki
Installable Unit:
As the name implies, Installable Units (IUs for short) describe things that can be installed, updated or uninstalled. They do not contain the actual artifacts but rather essential information about such artifacts (e.g., names, ids, version numbers, dependencies, etc) and are not aware about what they deliver. They describe things. They are NOT the things. So for example an IU for a bundle is NOT the bundle. The bundle is an "artifact". The metadata allows dependencies to be structured as graphs without forcing containment relationships between nodes. Here is detailed presentation of what an installable unit is made of.
In this context features and plug-ins are artifacts.
A plug-in in Eclipse is an OSGi bundle which may contain UI contributions and make use of Eclipse extension points.
A feature is a collection of plug-ins, fragments and features.