Many of you guys agree that the developers should not have write access to production servers (ie this question). In a such environment, who publishes a public-facing application/service/data? the testers?
We also have a small release team with special priviledges. They are out of the dev team, even though they are tecnical people.
A release is made of (if nok, any phase can be a stopper):
build a version
assemble a "what's new"
publish it internally for all sorts of tests, manual or automatic
access production databases to change run some scripts,
deploy the application in production,
make some minimal tests,
receive the customers complains
Most of the time, all the job is done by one person (another one is available as a backup).
The point of this is:
The same guy is less likely to make the same mistakes several times, he learns from mistakes.
This guy cannot shift the responsibility to someone else, so he really makes sure it will work.
This guy is not thinking about all the new exciting features that have been developped in that version, he doesn't even care. His focus is "what did they do this time that will break and get me in trouble :-(!". He is a counter-power actually, to the project managers that want theirs features delivered as soon as possible, and to the developpers that want all that fancy new code that is so cool!
At my company, we have a dedicated release engineering team that handles all deployments. Ideally, there is a disciplined process of review and testing that is followed, and the RE team can help ensure that actually happens.
Related
This is not a programming question, but I don't know any more active forum and besides programmers are the best people to be able to answer my question.
I am trying to understand the rationale behind continuous integration. On one hand, I understand that it is a good practice to daily commit your code before heading to home whether or not the coding and testing is complete or not and then there is continuous integration concept where the minute something is committed, it triggers a build and all the test cases are run. Aren't the two things contradictory?. If we commit daily whatever coding is done, it will cause daily failed builds..Why don't we manually trigger builds once the coding and testing is complete?.
Usually when you save your code daily is to be sure that your work will not be lost.
On the counterpart the CI or Continuous Integration is to test if what you produced is ok, in the majority of projects the CI isn't applied to individual branches ie: feature, bugfix, it's applied on major branches ie: master, develop, releases, etc. And these branches aren't updated daily as they need a pull request to be update and someone to approval that pull request.
The use case for having CI implemented on individual branches (feature, bugfix) is to check before merging a pull request into a major branch when it will check the tests and if the code builds.
So resuming, yes you need to commit your code daily, but you don't need to apply CI to it daily.
I suggest to you check the Gitflow workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
The answer is obvious.
1. Committing Code: In general the code is committed only after testing with the environment locally.
Consider Developer_A working on Component_A hence one has to commit with minimum verification as the scope is to develop Component_A.
No imagine complex system with 50 developer developing Component_B...Component_Z++
If someone is committing the code without minimum test it is most probably going to give you failed result.
Or else developer might have it committed on development branch that all together depends on SCM strategy adapted in project.
2. Continues Integration test scope:
On the other hand integrator principally collects and synergies different codes (Software Components) together into 1 container and perform different tests.
Most importantly, integrator need to ensure that all the Components Developed from different developers is fitting good and at the end Software is working as expected. To ensure that, Integrator have acceptance criteria and to proactively prevent something which can go wrong, it is important to have these criteria automated with the help of Continues integration.
But among all factors, it is important to give feedback on the quality of software to the developers. It is best in favor of project (economically), to know about the bug earlier hence Continues Integration and DevOps.
In Complex System it is worth to have automated watcher to catch the sneaked mistakes from developers.
3 Tools and Automation:
To create human independent system, automation tools like Jenkins are helpful.
Based on the testing strategy different testing levels can be performed with the help of Automation tools.
We have TFS 2013, currently for the team project working we don't have any branches, basically just a plain folder structure with various solutions in them.
With the goal to introduce release management, the intention is to create several branche, e.g. development/main/releases
As I was told I cannot 'disturb' the project team developers from their day to day work since there are other projects being worked on, question, what is the best practice to do this? Create a separate team project? How can we adopt the branching practice without asking all the developers.
Please help point a direction for this or share some thought on this, any help is appreciated!!
Unfortunately to do this you'll have to "disturb" the development team. You have 2 options. 1. Come up with a process in isolation and then disturb them when it goes live. 2. Collaborate with them on a process and work together to meet your requirements. (Being able to release your code to production is a key requirement for any project, sadly it's so obvious that it never gets added to the backlog / project plan and is always treated as a afterthought)
I recommend option 2. Without collaboration you're just going to end up causing resentment that you're imposing something on the Devs and they'll fight it tooth and nail. Also without the development team being involved you'll miss something important that will make the process brittle and difficult to maintain.
You'll need to get buy in from the Developers to implement a branching strategy as it will have a significant impact on them, they need to understand why you're doing this and what the benefits are, both to them and the business. They don't necessarily have to do any of the work, but they need to know what you're doing and why, they will also need to know when the changes are coming so that they can plan for the change.
Firstly you need to real the ALM Rangers version control guidance.
Secondly you need to get the developers to read it as well. They will be responsible for maintaining the code and merging it between branches. They will need to know when and where they need to check in various changes (such as hotfixes), and what process they should follow when code is ready for release.
Finally, regarding your question about where the branches should be located. It would be better to locate the all branches in the same Team Project rather than having your Dev branch in a separate Team Project.
We need CI on Heroku for our RoR app.
We want to use an add-on. I don't mind paying a few bucks to avoid complexity / distraction.
I see its basically Railsonfire vs. Tddium
What are the factors that we should consider in choosing to use one vs. the other?
A similar question was asked at the link below, but it appears that this was before the add-ons above were created.
Proper continuous integration and continuous deployment with Git and Heroku
Another option is CircleCi, which makes it incredibly easy, though it isn't yet in the Heroku add-on marketplace.
I personally believe speed is the major consideration. The speed at which your team moves is tied to how quickly you can get notifications, and a platform optimized for speed is going to make a major difference.
In addition, on slow platforms, tests may fail randomly (for example, Cucumber might fail if a button doesn't appear in 3 seconds, which may not happen soon enough on a slow platform).
I'm a founder of CircleCi, and we make an incredibly fast CI solution (faster than both services you mentioned). It's really easy to set up (one-click), though it's not in the Heroku marketplace (yet).
One consideration I'd give you to… uh… consider is support. I don't know anything about the Tddium team, but I do know that a couple months ago I tried Rails On Fire was blown away by the support. I asked some crazy questions (I do crazy things) and Florian responded in email and on Twitter right away with both help and suggestions.
Then, when I decided not to use the service because it couldn't support one edge-case feature, he implemented the feature! I hadn't been using it for a couple weeks and he wrote back to me personally to say "Hey, we finally got that feature you thought would be helpful."
I've used Hudson/Jenkins for years and know what you mean about complexity. But I also think that having someone on the other end is pretty key, and the RailsOnFire team, for now at least, do that quite well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am quite new to Lean/Kanban, but have poured over online resources over the last few weeks and have come up with a question that I haven't found a good answer for. Lean/Kanban seems otherwise such a good fit for our company, who is already using Scrum, but have reached some limitations inside that methodology. I hope someone here can give me a good idea.
As I see it, one of the biggest advantages of Scrum over Waterfall is the use of sprints. By having everything ready every 14 days you get short feedback cycles and can release often. However, as I have understood from reading about Lean, there are some costs associated with this (for example, time spent in sprint planning meetings, team commitment meetings & some problems with finding something useful for everyone at the end of the sprints).
Lean/Kanban will remove these wastes, but only at the cost of not being able to release every 14 days. Or have I missed an important point? For, in Kanban, how can you work on new development tasks and release at the same time? How do you make sure you don't ship something that is only halfway done? And how can you test it properly?
My best "solutions/ideas" so far are:
Don't release often and allow the waste associated with running out of new development tasks. Not really a solution to the question asked though.
Develop in branches and then merge into the main trunk. Makes you have to support at least two branches continuously internally.
Use some smart automatic labelling system to automatically build only certain finished tasks and not others.
As a summary, my question is: When you use Lean/Kanban, can you release often without introducing waste? Or is release often not part of Lean/Kanban?
Additional info specific to my company:
We use Team Foundation System & Source Control and have previously had some bad experiences in regards to branching and merging. Could this be solved simply by bringing in some expertise in this area?
The problem you describe seems more a source control program -- how to separate done features from features in-progress, than about Kanban. You seem to put a heavy penalty on running many branches -- which is the case for source control systems not based around the idea of multiple branches. On Distributed Source Control systems, such as GIT and Mercury, everything is a branch, and having them and working with them is lightweight.
I assume you read this blog about Kanban vs SCRUM, and the associated practical guide?
And, in answer to your question, yes, you can release often with Kanban.
You need to understand pull systems, which is what Kanban is designed to manage.
A customer (or product owner or similar) request for a feature in the running system is what triggers the process.
The request is a signal that goes to deployment. Deployment look for a tested item with properties that match the request. If none is there, you write the tests and look at development if there is a development slot that can be used to implement something that fulfils the test. When development has done its development (maybe looking for a suitable analysis first and so on), the test does its test, and deployment deploys.
The requests going backwards through the system are permissions to start working. As soon as the request has arrived, this triggers a lot of activity, where each activity should be completed as quickly as possible. There you have your turbo deployment.
Just like the request for a car goes to the dealer who looks in the ship who signals to the car factory, who signals to the suppliers.
Kanban is not about pushing requests through a system. It is about pulling functionality out of the system in exchange for a request that enters via the last step.
The team I manage uses Kanban and we release around every two weeks. If you're strict about what gets integrated into your mainline code branch (tests passing, customer approved, etc.), Kanban allows you to release whenever you want. You need to make sure that the stories moving through your system aren't co-dependent in order to do this, but on my team that's usually not a problem - a large part of our work involves maintenance, which consists of several unrelated bug fixes / features per release.
The way we handled weekly releases on a sustained engineering project that used Kanban was to implement a branching strategy. The devs worked in a sandbox branch, and made one checkin per work item. Our testers would test the work item in the sandbox; if it passed the regression tests the checkin would be migrated to our release branch. We locked the release branch from noon Monday until the release went out (usually by Wednesday, occasionally by Thursday, the drop dead date was Friday), and re-ran the regression tests for all migrated checkins as well as integration tests for the product, dropping a release once all of the tests passed.
This strategy let devs continually be working on issues without being frozen out of their branch during the release process. It also let them work on issues that took more than a week to resolve; if it wasn't checked in and tested/approved it didn't get migrated.
If I were running Kanban for a new version of a project, I'd use a similar strategy but group all related checkins as a 'feature', migrating a feature en masse to the release branch once the feature was done and then performing additional unit/integration/acceptance/regression testing in the release branch before dropping a release with that feature. Note that a key concept of Kanban is limiting work in progress, so I might restrict my team to work on one feature at a time (this would probably be several work items/user stories).
There's more to this than just source control, but your choice of TFS is going to limit you. When the Burton project was conceived back in 2004, Microsoft wasn't paying attention to Agile, much less Lean. It's going to be your weakest mechanical link for some time. Your hackles should have been raised by CodePlex's own adoption of Mercurial after having been offered to the Microsoft community as the poster child of TFS implementation.
A more salient issue here is Work Design. It encompasses the order that you choose to implement features (work schedule), as well as prioritization and cost of delay, and the shape and size of work items.
Scrum is commonly interpreted to say that non-technical "Product Owners" can determine work schedule based solely on their own concerns. If you follow this path, you're going to incur a lot waste by not taking the opportunities to do work together that belongs together. Work that belongs together can't just be determined by Product Owner wishes. Technical and workforce (skills) opportunities must also be taken into consideration.
For work to be done in the most productive way, the work itself has to be designed that way. This means that in a Lan Product Development team, decisions are made not by a non-technical worker, but by what Toyota calls someone of "Towering Technical Competence" who is close to the product, close to the customers, and close to the team.
This role is a stark contrast to Scrum's proposition. A Chief Engineer on a Lean team is himself (or herself) the voice of the customer, and the role of Product Owner is unnecessary.
Scrum's "Product Owner" is a recognition of an under-developed role in software development organizations, but it's far from a sustainable solution that consistently avoids waste. The role of "Software Architect" is often insufficient as well, as in some developer sub-cultures, the architect has become far too removed from the work.
Your issues of continuous deployment are only partially addressed with technology and tools. Look also to organizational issues, and perhaps give some thought to Scrum's purpose as a transitional approach from waterfall rather than one that can serve your organization indefinitely.
For source control I'd highly recommend Perforce. It makes branching and integrating changes from other branches relatively straightforward, and provides the best interface for source control that I've seen so far.
Continuous integration helps as well - i.e. lots of small, more than daily commits, instead of huge and potentially challenging merges. Tools like CruiseControl can help highlight when the source gets broken by a bad commit. Also, if everyone makes many small changes then conflicting changes will be rare.
I'd also advice not to try to follow things like lean, scrum, kanban & co. too closely. Just solve the problems yourself, looking to these ideas for guidance rather than instruction. The specifics of your problems will more than likely require some flexibility for the best management.
How we do it:
We have a pipeline with the following stages
Backlog
TODO
In progress (Develop and quick testing)
Code review
Test (Rigorous testing)
Integration test and general acceptance tests
Deploy
Each story is developed as a branch based on the latest version to leave the Deploy stage. They are then integrated as part of preparing the integration test.
QA pulls from the code review stage and can prepare releases at any pace the want. I think we have a pace of roughly one release every week.
By removing the "master" branch from git and not doing any merge before the code review stage we've made sure that there is no possibility to "sneak" code into releases. Which, as an interesting by-product, has forced us to visualize a lot of the work that used to be hidden.
My group is moving to Team Foundation Server soon. Actually, I'm heading up the effort.
One of the things you get to decide is which methodology you're using - Agile, CMMI, etc.
Thing is - I have no idea what methodology we use. By which I mean, we're not actively using one. And I'm not familiar enough with Agile or other methods to know which, if any, happen to apply to the way we're doing.
Is there some default methodology? As in, if we go through some very blunt process (get requirements, code, test, push to QA, have QA test, push to production) is there even a name for it?
And as a bonus, with TFS, what is the penalty for picking the wrong one at the outset? How hard is it to switch gears later if we decide to go Agile or something?
There's no major penalty for switching methodoligies - you just pick a default one when you install, and you can choose the one you'll use for any given project. In fact, it only has to do with how TFS configures the Sharepoint project page initially - you can add whatever you want to your page once it's created, so if you decide to change a project's methodology, it's not difficult to do.
For the two that TFS gives out of the box (Agile and SCCM/Waterfall), it really a question of your process - do you release "early and often", with smaller packages releases as bugs come in, or do you run your projects in large iterations, with a release much more infrequently, but with obvious milestone releases?
A question to ask (though not exactly accurate, but always helps me): Does the product have version numbers that will be meaningful to the end users? For example, many websites are Agile, as they're constantly releasing improvements and patches, and don't often have huge improvement/overhauls, whereas a product like MS Office has a meaningful version number (2003, 2007, etc), which is more likely SCCM.
If you don't have a stated methodology, it's a great time to develop one - decide which release cycle makes sense to you, create a project in each and review what TFS sets up for you automatically - do the progress indicators and Sharepoint pages make sense? Is there anything obvious missing?
If you can't discern a methodology, then you are using an ad-hoc methodology. It may be similar to an existing methodology (by accident). Note however that following a methodology is not the same as being successful. I have seen plenty of methodology heavy projects that failed, and plenty of "seat of the pants" projects be resounding successes (if perhaps in need of a bit of refactoring when the dust settled).
Changing methodologies depends on your culture more than anything. Institutions tend to resist change, and do some individuals. However, it is again situation dependent: if the existing situation is obviously broken, an institution can sometimes make snap changes that surprise everyone.
Some methodologies are "heavier" than others: those are harder to change to or from. Even Test Driven Development is "heavy" in that adopting it after the fact will mean adding a lot of tests to old code. Most real world transitions simply add the testing as files are edited for other reasons. Likewise, moving from TDD to some waterfall style would require a lot of code to be documented in large disused binders.
The most basic method tends to be your iterative or "waterfall method" because you just go from step to step to step. It doesn't seem to be very popular anymore, though.