I am doing reading on development methodology for my university course but both of these sound fairly similar.
"Staged Lifecycle is an Application Development methodology in which certain intermediate work products (incremental deliveries) will be delivered to the client before final delivery of the entire application"
"The incremental build model is a method of software development where the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished."
Can someone please explain to me the key differences between them?
My interpretation: The firs: every time a part of the product is finished it is send to the client. Eventually the client will have all the part and have the final product. The second: the product cannot be send to the client in between because it will not work. The product will be tested every time a part (depended on the previous) is finished until they reach the end result.
Related
I have two microservices, e.g M1 and M2. M1 is responsible for managing user transactions e.g orders. When an order is completed, the summary data is sent to M2 via Message bus. M2 is reponsible for generating reports on orders. Our transactions completes without checking if the message was processed successfully or not by M2. The problem is that some orders does not appear in the reports as the messages are not processed successfully(because of any Random Issue). What is the best way to make the data consistent between the two services. I am implementing a mechanism to pull data from M1 and identifying the gaps using the reference numbers(Its is a sequencial number) which I know is not a good approch as I may not know the last reference number that I have is actually the last. Any suggestions or improvements will be highly appreciated.
Thanks.
I have tried a pull data mechanism but I do not think that a good idea.
you may take a look at SAGA Pattern.
Saga goal is to form a Service span Transaction with capability of Compensate transaction.also you can use two phase commit pattern 2PC but it is not recommended mostly since it is resource span transaction which means it occupies resource until end of transaction and thats not good unless you insist immediate transaction which is short enough to release the resources soon as possible.
back to saga, you may hear the term called routing Slip. the routing slip forms chained steps to fulfill the transaction over services. this routing slip can be implemented in two ways of choreography and orchestration. in case of failure happened in any steps the compensation will triggered for all steps that are done. this compensate may be a rollback or any other strategy that should take place. eg :
order added
the inventory item allocated
shipping service proceeded with error and compensate take place as
the allocated item in inventory released
order removed or canceled
i use Masstransit.
read SAGA State Machine where the steps in transaction are coordinated and updates the state for the transaction
read Courier Routing Slip where the routing slips for transaction are defined.
watch Masstransit Serries tut by Chris Patterson
Also, please consider retry policy in case of failure occurred. it can be done with Masstransit configuration.
currently we are having the following states/columns in JIRA:
Open/Todo (-> Developer takes task and starts work)
In Progress (-> Developer sets tasks to done)
Done (-> QA tests on staging and sets task to ready to deploy or reopens)
Ready to deploy (-> Developer deploy these tasks at date of release)
Deployed (-> QA/Stakeholder tests task again on Live/Production and closes or reopens)
Done/Closed
In my current understanding this is wrong, because we try to handle two concerns in one status dimension: Development and deployment. I would like to decouple sprint from release/versions. Currently we cant end a sprint until all tickets are approved on production which leads to bottlenecks.
What would be your suggestion? One idea I have in mind: Limit the status to Open, In Progress, Done, Closed and handle the deployment/release over JIRA build-in versioning. If a problem occures on production, a bug ticket must be opened.
Otherwise I don't see a chance since the versioning/releasing of JIRA 6.4 does not seem to include status columns by itself.
Is releasing to production part of your team's 'definition of done'? If it is then the workflow you have makes a lot sense.
There is no separation of concerns between development and deployment. Code that has been developed but not deployed has no value to the business. Development is simply a step in the process towards release, which is the point at which value is realised.
A sprint is a timebox, not a set amount of work. When the timebox ends then the work that you have still in progress is not 'done'. If you are regularly unable to complete all the work you bring in to a sprint then that suggests you are bringing too much work in. The team's velocity, which is a measure of the work that gets 'done' each sprint, should be a good indication of what your sprint capacity is.
If your bottleneck is the release to production and verification of the release, then perhaps you should focus some effort on improving this process? Possibly this could mean more release automation or better coordination with the stakeholders over validating releases.
What is the role of BPM (BussinessProcessManagement) in a realtime application?
I mean in which cases or where is BPM actually used?
I could get the documentation from the net, but where actually is it used?
One definition of BPM is that is combines workflow management (humans interacting) with enterprise application integration (EAI, systems interacting). You can get applications and tools for those applications - sometime embedded - which you can use to define you business process. Then, in a staging process, you can roll out the business process to that system or a set of applications. To execute a business process (BP) you can use a business process engine (e.g. jBPM), and each step of a business process can be represented by a user interaction, a user task, a system task or variations of these. You can have parallel business steps that only once all of these complete can go to the next business process step. And there is much more to that.
Once you have rolled out a business process you can monitor it and collect data for a number of parameters. Often you will be interested how long a business process took and what the limiting factors are, e.g. how many manual steps are required. Then you can go back to the designer tool and modify the process. With data taken from the production system you can then simulate whether your changes are actually an improvement. And if they are you roll it out replacing the previous version.
On a smaller scale you can workflow designer or business process designers to allow user changing a particular part of a process. Often applications have hard-coded business process support with only limited parameterization/configuration. Take an approval process. Which purchases need approval? By whom? Could multiple people approve in parallel thus shortening the purchasing process? You application may offer your users to design the approval process as needed. It would no longer be hard-coded and allow for much better adaptation to the needs of your customer.
These are just a few thought and definitely not a full coverage of this subject. But maybe it already gives some idea.
BPM can be used in Health care application for integrating various systems and in banking field for loans aplication processing where human involvement is involved in different steps for loans approval, and in health care industry it is used mostly used for bundle of claims which we receive every day for cliams processing and for business state in which state to know.
and in The airline Reservation System for ticket booking process how the process moves one one level to another ex: adding passenger to flight.
My organization is building a new version of our ticketing site and is looking for the best way to build an online waiting room when the number of users in our purchase path exceeds a certain limit. The best version of this queue would let new users in after existing users have either completed their purchase or have exceeded a timeout limit after entering the path.
I'm trying to get an idea of how this has been implemented by other organizations. Has anyone out there done something similar or have any experience with this? We have some ideas, but I'd like to get a sense of what solutions have been tried and what problems those solutions have run up against.
Just to be complete, this site is being built in Ruby on Rails, though I'd love to hear about how people have solved this regardless of platform.
Edit: To clarify: The need for the queue is not primarily to reduce load, but to limit the speed at which the web is purchasing tickets relative to people buying in other ways, like over the phone.
Before I outline one method for this, I want to point out that what you want to do doesn't make a lot of sense. Services on the web aren't like a physical store, where I can walk up and see that it's crowded and decide to stay or not. Queueing people on your site strikes me as shifting the blame from you (unable or unwilling to adequately provision resources) to me (punishing me for trying to use your site).
If you're selling something like show tickets, where quantity is limited and each item is tied to a seat, I think it's better to reserve items and time out those reservations if they aren't paid for in a timely manner. Ticketmaster does this, and I think it's a much better solution than blocking people at the door.
If you still want to go down this path, then I'd design the system like this:
As customers come to your site, record their arrival time. As they interact with the site, record a "last seen" time. "Last seen" will be used to determine activeness. You'll need a background job running very frequently to expire sessions quickly.
Once your limit is hit, you have an ordered queue of people who are blocked. As customers complete their transaction or time out, you'll mark the next person in the queue for entry into the purchase path.
For queued users, their browsers will make a request on a regular basis, checking to see if you've let them in yet. If yes, they proceed to the purchase path. If no, they continue to wait.
The purchase path needs a mechanism to check if someone is trying to circumvent your waiting area, and sends them back.
You might find the Online queuing for ticketing guide helpful. Check their repository at GitHub.
They've integration with Ruby On Rails, PHP, .NET, iOS, Android and similar platforms.
Queue-it enables you to gain control of website overload during extreme traffic peaks by offloading end users into an online queue.
When a peak traffic event occurs on a website, the online queue system sends users to the virtual waiting room environment where the users wait and are redirected back to the website at a rate it can handle.
I am curious on how others manage code promotion from DEV to TEST to PROD within an enterprise.
What tools or processes do you use to manage the "red tape", entry/exit criteria side of things?
My current organisation is half stuck between some custom online forms type functionality and paper based dependencies to submit documents, gather approvals and reviews.
All this is left in the project managers hands to track what has been submitted, passed review, approved and advise management if there are any roadblocks that may need approval to be "overlooked" before an application can be promoted to the next environment.
A browser based application would be ideal... so whats out there? please show me that you googlefu is better than mine.
It's hard to find one that's good via google. There is a vast array of tools out there for issue management so I'll mention what we use and what we woudl like to use.
We currently use serena products. They have worked well for us in the past. Team Track is our issue management and handles the life cycle of any issue we work on. Version Manager is our source control and has the feature of implementing promotional groups like DEV TEST And PROD. We use DEV, TSTAGE, TEST, PSTAGE and PROD to signify the movement from one to the other, but it's much the same. The two products integrate nicely so that the source associated with the issues is linked, but we have no build process setup in this environment. It's expensive, but it works well.
We are looking ot move to a more common system using Jira for issue management, Subversion for source control, Fisheye to link the two together and Cruise Control for build management. This is less expensive, totaling a few thousand for an enterprise lisence and provides all the same features but with the added bonus of SVN which is a very nice code version mangager.
I hope that helps.
There are a few different scenarios that I've experienced over the years:
Dev -> Test : There is usually a code freeze date that stops work on new features and gets a test environment the code that has been tagged/labelled/archived that gets built. This then gets copied onto the machines and the tests go fine. This is also usually the least detailed of any push.
Test->Prod : This requires the minor change that production has to go down which can mean that a "gone fishing" page goes up or IIS doesn'thave any sites running and the code is copied over again. There are special cases to this where a load balancer can act as a switch so that the promotion happens and none of the customers experience any down time as the ones on the older server will move once their session ends.
To elaborate on that switch idea, the set up is to have 2 potentially live servers with just one server taking requests that the load balancer just sends all the traffic to one machine that can be switched when the other server has the updated code to go live.
There can also be a staging environment which is between test and production where the process is similar in terms of there is a set date when the promotion happens.
Where I used to work there would be merge days where a developer spent most of a day in Perforce merging code so that it could be promoted from one environment to another.
Now there are a couple of cases where this isn't used:
"Hotfixes" or "Hot patches" would occur where I used to work and in this case the specific files were copied up into the staging and production environments on its own since the code change had to get into Production ASAP since something broke in production or some new thing that had to get done that takes 2 minutes gets done. In this case, the code change getting pushed in had to be reviewed and approved before going out.
Those are the different approaches I've seen used where generally there are schedules and timelines potentially have to be changed or additional resources brought in to make a hard date like if a conference is on a particular weekend that such and such is ready for that.
Of course in a few places there has been the, "Oh, was that broken? Let me see..." and a few minutes later, "No, see it isn't broken for me," where someone changed things without asking permission or anything where a company still has what they call "cowboy programming."
Another point is the scale of the release:
1) Tiny - This is the case where one web page goes up so that user X can do Y.
2) Small - A handful or so of files that isn't really complicated but isn't exactly trivial.
3) Medium - Where going from one environment to another requires changing a bunch of files and usually has scripts to move.
4) Big - Where there are scheduled promotions and various developers are asked for who is taking which shifts when the live push is done. I had this in a case where there was a data migration to do in addition to a release of some new e-commerce sites.
5) Mammoth - Where everything is brand new including how this would be used. I don't think I've ever seen one of this size but I'd imagine Microsoft or Google would have releases of this size.
Somewhere in that spectrum most releases fall and so how much planning and preparation can vary quite a bit and let's not forget that regulatory compliance can be its own pain in getting some things done.